为什么你的 AI 协作总是"跑偏"？——用状态机重新设计 AI 任务

你有没有遇到过这些情况：

场景1：上下文丢失

text

你：帮我重构这个登录模块，记得要保持向后兼容
AI：好的，我重构了（30分钟后）
你：测试覆盖率怎么样？
AI：什么测试覆盖率？你之前没提过啊

场景2：目标漂移

text

你：修复这个 bug，顺便优化一下性能
AI：（开始重构整个架构）
你：等等！我只是要修个 bug！
AI：但是这样更好啊...

场景3：无法验证

text

你：任务完成了吗？
AI：完成了
你：真的完成了？测试通过了吗？文档更新了吗？
AI：呃...你说的"完成"是指...

这三个问题的本质是什么？

AI 没有"工作记忆"，每次对话都是新的开始。传统的"聊天式协作"让 AI 任务像一团乱麻：

上下文隐含在对话历史中（AI 容易丢失）
目标模糊在自然语言里（AI 容易理解偏）
完成标准藏在你脑子里（AI 根本不知道）

解决方案：用状态机思维重新设计 AI 任务

状态机是什么？

别被"状态机"这个词吓到，其实你天天在用：

红绿灯就是状态机

text

当前状态：红灯
输入条件：等待30秒
下一状态：绿灯
验证标准：灯变绿了

自动售货机也是状态机

text

当前状态：等待投币
输入条件：投入5元硬币
下一状态：可以选商品
验证标准：屏幕显示"请选择商品"

状态机的核心思想：

明确"现在在哪"（当前状态）
明确"要去哪"（目标状态）
明确"怎么去"（转移条件）
明确"到了没"（验证标准）

AI 任务状态机：5个要素

我们把状态机思想映射到 AI 任务管理，定义5个核心要素：

1. 初始状态 (q₀)：任务开始时，系统是什么样的

不是：要做什么（那是任务需求）而是：现在是什么样

举例：重构登录模块

yaml

初始状态:
  代码：
    - auth.js 有 350 行
    - 包含 login/logout/validateToken 三个函数
  测试：
    - 15 个测试用例
    - 覆盖率 60%
    - 全部通过
  文档：
    - README 有基础说明
    - 缺少 API 文档
  已知问题：
    - 密码重置功能有 bug
    - session 过期时间过短

2. 目标状态 (F)：任务完成时，系统应该变成什么样

关键：这是一个集合，不是单一状态（允许多种可接受的完成状态）

举例：

yaml

完美完成:
  代码：重构完成，复杂度降低，性能提升 20%
  测试：覆盖率 > 90%，所有测试通过
  文档：完整的 API 文档 + 迁移指南
  问题：所有已知 bug 修复

可接受完成:
  代码：重构完成，向后兼容
  测试：覆盖率 > 80%，主要测试通过
  文档：API 文档完成

最小可交付:
  代码：核心功能重构完成
  测试：主路径测试通过
  文档：README 更新

3. 上下文空间 (Σ)：任务执行需要的所有背景信息

关键：这些信息在任务执行期间不变（或缓慢变化）

分为四层：

层次	内容	示例
信息层	现有代码、设计文档、API规范	现有 auth.js 源码、技术方案文档
约束层	技术栈、性能要求、兼容性	必须使用 TypeScript、支持 Chrome 90+
规范层	代码风格、测试要求、提交规范	ESLint 配置、覆盖率 > 80%
关联层	依赖任务、后续任务、并行任务	用户模块已完成，支付模块等待本任务

4. 转移函数 (δ)：AI 本身的执行能力

这是 AI（或智能体）的工作：

yaml

AI 的能力:
  理解：理解初始状态和目标状态
  规划：自主决策执行路径
  执行：调用工具完成工作
  验证：确认是否达到目标状态

关键特点：

我们不控制 AI 内部如何思考（黑盒）
我们只控制输入和期望输出
相同输入可能产生不同路径（非确定性）

5. 生产态空间 (Q)：任务执行过程中所有可能的工作成果状态

重要区分：

❌ 运行态：AI 正在读文件、正在思考（我们不关心）
✅ 生产态：代码写到什么程度、测试通过多少（我们关心的）

两个核心保证：原子性 + 一致性

原子性：任务要么全部完成，要么全部不做

传统方式的问题：

text

你：帮我实现用户注册功能
AI：（写了一半代码）
你：等等，我还要加个验证码
AI：（继续写）
你：不对，邮箱验证也要加上
AI：（代码越来越乱）
最后：半成品，无法使用

状态机方式：

yaml

初始状态：用户模块没有注册功能

目标状态：注册功能完整
  - 包括表单、验证、邮件确认

验证标准：
  - 用户可以注册
  - 收到确认邮件
  - 点击链接激活账户
  - 所有测试通过

结果：要么达到这个状态，要么回到初始状态
      中间状态不可交付

如何保证：

明确定义"完成"的标准（目标状态 F）
任务结束时验证是否达到 F
未达到 F = 任务失败，需要重新执行或回滚

一致性：相同输入应该产生相同结果

传统方式的问题：

text

第一次：
你：帮我写个用户认证模块
AI：（用 JWT）

第二次（同样的话）：
你：帮我写个用户认证模块
AI：（用 Session）

你：？？？为什么不一样

状态机方式：

yaml

输入固定：
  初始状态: {代码库现状、技术栈、规范...}
  上下文空间: {必须用 JWT、参考已有的权限模块...}
  目标状态: {认证功能完成、测试通过...}

保证：只要这三个输入相同，AI 产出应该一致
      （即使路径可能不同，但最终结果符合目标状态）

如何保证：

显式定义所有约束（上下文空间 Σ）
包括技术选型、参考实现、设计模式
不依赖"AI 自己判断"

实战案例：用状态机定义一个真实任务

需求：为博客系统添加评论功能

传统方式（聊天式）

text

你：帮我加个评论功能
AI：好的（开始写代码）
你：要支持回复
AI：好（加回复功能）
你：还要有点赞
AI：行（继续加）
你：要不要加举报功能？
AI：可以啊（越写越多）
...（3小时后，一团乱麻）

状态机方式

1. 初始状态 (q₀)

yaml

代码状态：
  - 已有 Post 模型（标题、内容、作者）
  - 已有用户认证系统
  - 数据库：PostgreSQL

测试状态：
  - Post 相关测试覆盖率 85%

技术栈：
  - 后端：Node.js + Express + TypeORM
  - 前端：React + TypeScript

2. 上下文空间 (Σ)

层次	具体内容
信息层	• 现有 Post 模型代码 • 用户认证实现方式 • 数据库 Schema
约束层	• 必须使用 TypeORM • 评论不能超过 1000 字 • 需要防 XSS 攻击
规范层	• RESTful API 设计 • 测试覆盖率 > 80% • 代码必须通过 ESLint
关联层	• 依赖：用户认证模块（已完成） • 并行：前端 UI 改版（进行中）

3. 目标状态 (F)

完整完成：

yaml

功能：
  ✓ 用户可以发表评论（需登录）
  ✓ 支持二级回复（回复评论）
  ✓ 支持点赞评论
  ✓ 评论作者可以编辑/删除自己的评论
  ✓ 管理员可以删除任何评论

技术：
  ✓ Comment 模型已创建（id, postId, userId, content, parentId, createdAt）
  ✓ RESTful API 实现（POST /comments, GET /posts/:id/comments, DELETE /comments/:id）
  ✓ 前端组件完成（CommentList, CommentForm, CommentItem）

质量：
  ✓ 测试覆盖率 > 85%
  ✓ XSS 防护已实现
  ✓ API 文档已更新

最小可交付：

yaml

功能：
  ✓ 用户可以发表评论
  ✓ 可以查看评论列表

技术：
  ✓ Comment 模型创建
  ✓ 基础 API 实现

质量：
  ✓ 主路径测试通过

4. 验证清单

任务结束时，逐项检查：

yaml

功能验证：
  [ ] 登录用户可以在文章下发表评论
  [ ] 评论立即显示在评论列表中
  [ ] 可以回复评论（二级回复）
  [ ] 可以点赞评论
  [ ] 作者可以编辑自己的评论
  [ ] 作者可以删除自己的评论

技术验证：
  [ ] npm test 全部通过
  [ ] npm run lint 无错误
  [ ] API 符合 RESTful 规范

安全验证：
  [ ] 评论内容经过 XSS 过滤
  [ ] 未登录用户无法发表评论
  [ ] 用户只能编辑/删除自己的评论

5. 执行

AI 基于 (q₀, Σ, F) 自主决策执行路径，过程中：

创建数据库 Migration
实现 Comment 模型
开发 API 端点
编写前端组件
编写测试用例
更新文档

关键：AI 的执行路径可能不同，但最终必须满足验证清单（达到 F）

传统方式 vs 状态机方式对比

维度	传统聊天式	状态机式
上下文管理	隐含在对话历史容易丢失	显式定义在 Σ 中始终可见
目标定义	模糊的自然语言 "做个功能"	明确的状态描述可验证的清单
完成判断	主观感觉 "看起来差不多了"	客观验证清单全部打勾
可预测性	每次结果不同看运气	输入相同，结果一致可复现
可组合性	任务间难以串联上下文断裂	任务间状态清晰传递可组成工作流
原子性	经常半途而废留下半成品	要么完成要么失败不留半成品
并行协作	多个 AI 互相冲突谁也不知道谁在做什么	状态清晰，可并行通过状态接口协作

这套方法的核心价值

1. 让 AI 任务变得可控

可控的三个维度：

可预测：相同输入 → 相同输出
可验证：明确的完成标准
可替换：换个 AI，结果一致

2. 让 AI 协作变得可靠

可靠的保证机制：

原子性：任务要么成功，要么失败，不留半成品
一致性：多次执行结果一致
隔离性：任务间不互相干扰
持久性：状态转移可追溯

3. 让 AI 工作流变得可组合

任务网络：

text

任务A的目标状态 → 任务B的初始状态
任务B的目标状态 → 任务C的初始状态
...
形成可组合的工作流

下一步：如何实践

对于产品经理/项目经理

定义任务时，问自己5个问题：

初始状态是什么？（现在什么样）
目标状态是什么？（要变成什么样）
需要什么上下文？（AI 需要知道什么）
如何验证完成？（完成标准是什么）
可以接受的最小完成状态是什么？（MVP 是什么）

对于技术 Leader

落地时，做三件事：

建立任务模板：标准化任务定义格式
构建上下文库：维护项目的技术栈、规范、设计文档
设计验证流程：自动化测试 + 人工检查清单

对于 AI 工具开发者

实现时，考虑三个层次：

任务引擎：解析状态机定义，驱动 AI 执行
状态管理：记录状态转移轨迹，支持回溯
验证框架：自动化检查目标状态是否达成

总结

核心思想：

用状态机思维重新设计 AI 任务
关注"生产态"（产出了什么），而非"运行态"（正在做什么）
显式定义初始状态、目标状态、上下文、验证标准

核心价值：

保证原子性：任务要么全部完成，要么全部不做
保证一致性：相同输入产生相同结果
提升可控性：AI 任务从"看运气"变成"可预测"

从哪里开始：

下次给 AI 布置任务时，先想清楚这5个要素
不要再说"帮我做个功能"
而是说"从状态A到状态B，需要满足条件C"

AI 协作的未来，不是更聪明的 AI，而是更清晰的任务定义。

延伸阅读：

讨论：

你在 AI 协作中遇到过哪些"跑偏"的情况？欢迎在评论区分享你的经历。

解决方案：用状态机思维重新设计 AI 任务 ​

状态机是什么？ ​

AI 任务状态机：5个要素 ​

1. 初始状态 (q₀)：任务开始时，系统是什么样的 ​

2. 目标状态 (F)：任务完成时，系统应该变成什么样 ​

3. 上下文空间 (Σ)：任务执行需要的所有背景信息 ​

4. 转移函数 (δ)：AI 本身的执行能力 ​

5. 生产态空间 (Q)：任务执行过程中所有可能的工作成果状态 ​

两个核心保证：原子性 + 一致性 ​

原子性：任务要么全部完成，要么全部不做 ​

一致性：相同输入应该产生相同结果 ​

实战案例：用状态机定义一个真实任务 ​

传统方式（聊天式） ​

状态机方式 ​

1. 初始状态 (q₀) ​

2. 上下文空间 (Σ) ​

3. 目标状态 (F) ​

4. 验证清单 ​

5. 执行 ​

传统方式 vs 状态机方式对比 ​

这套方法的核心价值 ​

1. 让 AI 任务变得可控 ​

2. 让 AI 协作变得可靠 ​

3. 让 AI 工作流变得可组合 ​

下一步：如何实践 ​

对于产品经理/项目经理 ​

对于技术 Leader ​

对于 AI 工具开发者 ​

总结 ​

解决方案：用状态机思维重新设计 AI 任务

状态机是什么？

AI 任务状态机：5个要素

1. 初始状态 (q₀)：任务开始时，系统是什么样的

2. 目标状态 (F)：任务完成时，系统应该变成什么样

3. 上下文空间 (Σ)：任务执行需要的所有背景信息

4. 转移函数 (δ)：AI 本身的执行能力

5. 生产态空间 (Q)：任务执行过程中所有可能的工作成果状态

两个核心保证：原子性 + 一致性

原子性：任务要么全部完成，要么全部不做

一致性：相同输入应该产生相同结果

实战案例：用状态机定义一个真实任务

传统方式（聊天式）

状态机方式

1. 初始状态 (q₀)

2. 上下文空间 (Σ)

3. 目标状态 (F)

4. 验证清单

5. 执行

传统方式 vs 状态机方式对比

这套方法的核心价值

1. 让 AI 任务变得可控

2. 让 AI 协作变得可靠

3. 让 AI 工作流变得可组合

下一步：如何实践

对于产品经理/项目经理

对于技术 Leader

对于 AI 工具开发者

总结