这一期周刊把主菜做成了一篇小说：《我在智念 AI 的日子》。公开摘要只说明它是每周科技内容分享的一部分，具体情节没有展开；但题目已经足够有意思：当“AI 公司”“工作日常”“叙事”放在一起，读者不只是看故事，也会自然追问一个工程问题：一个围绕 AI 运转的组织，风险到底藏在哪些流程里？
下面不复述小说细节，而是把它当作一个技术讨论入口：如果我们在真实团队里建设 AI 产品，怎样把灵感、焦虑和判断落到可执行的工程清单上。
小说适合揭开的，不只是技术栈
AI 产品的复杂度，往往不在某一个模型 API，而在模型进入组织之后的连锁反应：需求会被重新定义，测试标准会变模糊，客服、运营、法务和研发开始共享同一个不稳定变量。
这类题材的小说有价值，是因为它能把几个平时被拆开的东西放回同一张桌子上：
- 模型输出不是“函数返回值”，它更像一个带概率的同事意见。
- 产品体验不是只看 demo，还要看失败时谁兜底。
- AI 公司里的速度感，可能同时来自工程突破和流程透支。
- 一个看似聪明的 Agent，一旦接上真实权限，就不再只是聊天窗口。
技术团队读这种文本，不必急着判断它“准不准”。更有用的读法是：把其中的组织张力翻译成系统边界、权限边界和验收标准。
把 AI 叙事翻译成工程问题
如果一个故事里出现“自动化决策”“模型替人处理任务”“公司依赖某个 AI 系统”等元素，工程上至少要问四组问题。
第一组是输入问题：数据从哪里来，是否经过授权，是否包含敏感信息，是否会因为提示词拼接而泄露上下文。
第二组是输出问题：模型给出的结果能不能被验证，错误会不会静默进入业务系统，是否需要人工复核。
第三组是权限问题：AI 能读什么、写什么、调用什么接口，失败时有没有熔断和审计日志。
第四组是组织问题：谁定义“可用”，谁负责事故，谁有权暂停上线。
很多 AI 项目的风险不是“模型突然失控”这种戏剧化场景，而是很普通的工程缺口：没有记录 prompt 版本，没有固定评测集，没有区分建议和执行，没有给高风险动作加确认。
可以这样实践：给 AI 功能做一个轻量风险登记表
下面这个示例不是来源事实，而是一个可改造的小工具。它用 Python 标准库读取一组 AI 功能清单，按“数据敏感度、动作权限、人工复核、日志审计”计算粗略风险等级。你可以把它放进项目仓库，作为评审前的自检脚本。
保存为 ai_risk_check.py 后直接运行：
from dataclasses import dataclass
@dataclass
class AIFeature:
name: str
data_sensitivity: int # 0-3: public, internal, personal, regulated
can_write: bool
calls_external_tools: bool
human_review: bool
audit_log: bool
def score(feature: AIFeature) -> tuple[int, list[str]]:
points = feature.data_sensitivity
reasons = []
if feature.data_sensitivity >= 2:
reasons.append('handles personal or regulated data')
if feature.can_write:
points += 2
reasons.append('can modify business state')
if feature.calls_external_tools:
points += 1
reasons.append('can call tools or external APIs')
if not feature.human_review:
points += 2
reasons.append('has no human review')
if not feature.audit_log:
points += 1
reasons.append('has no audit log')
return points, reasons
def level(points: int) -> str:
if points >= 6:
return 'HIGH'
if points >= 3:
return 'MEDIUM'
return 'LOW'
features = [
AIFeature('support_reply_draft', 2, False, False, True, True),
AIFeature('auto_refund_agent', 2, True, True, False, True),
AIFeature('weekly_report_summary', 1, False, False, False, False),
]
for item in features:
points, reasons = score(item)
print(f'{item.name}: {level(points)} ({points})')
for reason in reasons:
print(f' - {reason}')
运行：
python ai_risk_check.py
你需要改的地方很少：把 features 换成你们真实的 AI 功能列表，把 data_sensitivity 的分级改成团队自己的数据分类规则。这个脚本不替代安全评审，但它能让讨论从“感觉有风险”变成“这个功能为什么是高风险”。
更像工程检查表，而不是读后感
读 AI 小说时，工程师最容易带走的不是情节，而是一组问题。下次团队准备上线一个 AI 功能，可以用下面的清单收口：
- 是否记录了模型、prompt、工具权限和配置版本？
- 是否有固定评测样本，覆盖正常输入、恶意输入和边界输入？
- 高风险动作是否默认只生成建议，而不是直接执行？
- 是否有人工复核入口，以及明确的责任人？
- 是否能追踪一次输出使用了哪些输入、调用了哪些工具？
- 是否定义了暂停开关、回滚方式和事故通知路径？
《我在智念 AI 的日子》这样的题目提醒我们：AI 的故事不会只发生在模型层。它发生在工单、会议、权限、日志和上线审批里。真正成熟的团队，不是完全避免风险，而是能把风险命名、量化、记录，并在它扩大之前按下刹车。