最近做项目时遇到一个很明显的问题：接触到的新需求越来越接近全栈，但自己对服务端和后端工程的实战经验并不充分。于是很多时候会依赖 AI 来拟定方案、拆任务、写代码，再由我来阅读和判断。
这里真正危险的地方不在于“用了 AI”，而在于读完方案之后经常会得到一种感知：这个方案是合理的。
这种感知未必可靠。一个方案看起来合理，可能只是因为它的表达完整、结构顺畅、术语正确，并不代表它真的经得起真实系统里的并发、权限、数据一致性、失败重试和线上排障。对于自己并不熟悉的领域，所谓“合理”很可能只是一种叙事上的顺滑。
换句话说，AI 可以很快给出一个工程方案，但它不会自动把判断力也交给我。
“合理感”为什么会变成风险#
前端场景里，很多问题可以通过页面表现、交互路径和本地状态快速暴露。样式错了、状态没更新、接口返回没处理，大多能在较短反馈链路里看到。
后端不是这样。
后端问题经常不以“马上坏掉”的形式出现，而是以更隐蔽的方式积累：数据被重复写入，权限边界没有兜住，状态流转缺了一条分支，失败重试制造了副作用，某个接口在小流量下正常但在并发下出现竞争条件。更麻烦的是，很多问题只有在上线后、数据进入系统后、多人协作之后才会真正暴露。
这也是我开始重新看待 AI 辅助开发的原因。AI 最大的优势是把从想法到产物的距离压短，但这也会压短“怀疑”和“验证”的时间。代码出现得越快，越容易让人误以为问题已经被解决。
如果缺少领域经验，AI 生成的方案就会变成一种抽奖：有时它确实很好，有时只是看起来完整。
structured-ai-dev-workflow 解决了什么#
之前我写过一个开发 skill：structured-ai-dev-workflow。它的核心思路是把 AI 开发过程拆成一套可追踪的闭环：
- 先沉淀需求
- 再 research 现有实现
- 然后写 plan
- 再拆 phase task
- 实现后写 worklog
- 每个阶段尽量可验证、可提交、可接续
这个结构在中大型需求里很有价值。它解决的是 AI 开发中很常见的几个问题：上下文丢失、范围失控、边做边忘、后续无法接手、提交粒度混乱。尤其当工期比较长、需求可以拆阶段推进时，它能建立一个相对健康的优化循环。
但现在回头看，它也有一个明显前提：research 和 plan 的质量是可信的。
如果研究和计划本身就存在盲区，那么后面的 task、implement、worklog 只能把这个盲区结构化地传递下去。流程越完整，甚至越容易让人产生“这件事已经被认真处理过”的错觉。
也就是说，structured-ai-dev-workflow 更像是过程管理工具，而不是工程风险审查工具。它能让开发过程更可控，但不必然让方案更可靠。
这个 workflow 在短工期下的问题#
完整的结构化开发流程，比较适合下面几种情况：
- 需求足够大，值得单独拆阶段
- 工期允许先 research、再 plan、再实现
- 现有系统有足够资料可查
- 开发者对领域有基本判断力
- 每个 phase 都能独立验证
但真实项目经常不是这样。很多需求的状态更接近：
- 工期短
- 业务催得急
- 领域不熟
- 代码已有历史包袱
- 测试覆盖不足
- 只能先交付一个可用版本
在这种情况下，如果仍然照搬完整流程，会出现两种问题。
一种是流程太重。文档写完，时间已经被消耗掉，真正用于实现和验证的空间变小。
另一种是流程被压缩得太轻。research 和 plan 变成几段概括，风险没有真正展开，最后只是把“直接写代码”包装成“按流程写代码”。
这不是流程本身的问题，而是模式选择的问题。在短工期和陌生领域里，真正需要优先建立的不是完整闭环，而是风险优先的交付机制。
grill-me 的价值和边界#
grill-me 这类工具有价值。它通过持续追问，把需求、决策、边界和依赖关系问清楚。它适合发生在编码之前，帮助人和 AI 一起澄清“到底要做什么”。
但它不能直接替代代码 review。
需求被问清楚，只能说明目标更明确；并不说明实现结构可靠，也不说明数据模型、权限边界、错误处理和并发行为都没有问题。尤其在后端场景里，很多关键问题并不是“需求有没有说清楚”，而是“实现是否在坏情况里仍然可控”。
因此，grill-me 的思想可以迁移，但角色需要改变。
编码前的 grill-me 问的是：
- 用户真正想要什么？
- 哪些场景需要覆盖？
- 哪些边界需要确认？
- 哪些决策会影响后续实现？
编码后的 review grill 应该问的是：
- 这个实现在哪些情况下会写错数据？
- 哪些权限判断只存在于前端或调用方假设里？
- 重复请求会不会产生重复记录？
- 多步写入失败后会不会留下半成品？
- 错误日志是否足够定位线上问题？
- 数据库约束是否兜住了业务不变量？
- 这个抽象是在降低复杂度，还是在隐藏复杂度？
前者帮助进入编码，后者帮助判断能不能交付。两者解决的是不同问题。
需要补上的不是更多文档，而是 review gate#
现在更应该补在 workflow 里的，不是再多一层计划文档，而是一个明确的风险审查关口。
这个关口可以放在 plan 之后，也可以放在实现之后。对后端或全栈需求来说，它应该至少覆盖几类问题：
- 数据一致性：多步写入是否需要事务，失败后是否可恢复
- 权限边界：用户是否只能访问自己应该访问的资源
- 幂等和重复提交：刷新、重试、重复点击是否会制造副作用
- 输入校验：不可信输入是否在服务端被重新检查
- 状态流转：状态枚举是否完整，非法状态是否被阻止
- 可观测性：出问题后能否通过日志定位到请求、用户和数据
- 回滚和补偿：上线后如果出错，是否知道如何修复已有数据
这些问题不一定都需要复杂实现，但必须被显式讨论。短工期下可以接受一些风险，但不能在不知道风险是什么的情况下接受风险。
这也是我现在对 AI 开发流程的一个修正：AI 不应该只负责生成方案，还应该被强制放到反方位置上，持续攻击自己的方案。
skill review 和多轮 review#
这里还有一个值得补充的问题：即使使用各种 skill 去 review，实际效果也不一定稳定地好过“多重复几轮让 AI 去 review”。
这听起来有点反直觉。skill 的价值在于结构化，它能规定审查维度，提醒 AI 不要漏掉权限、数据一致性、幂等、日志、回滚这些关键问题。但它并不保证每一次审查都有足够高的召回率。AI 仍然可能沿着某一条思路检查得很细，却漏掉另一类问题；也可能因为第一次 review 的结论太顺，后续就不再主动怀疑。
多轮 review 的价值恰好在这里。它不是依赖某一个“完美 reviewer”，而是通过重复采样，让模型从不同角度重新进入问题。第一轮可能看到权限问题，第二轮可能看到事务问题，第三轮可能开始怀疑状态机，第四轮才注意到日志和回滚。很多时候，问题不是靠一次很完整的模板发现的，而是靠多次不完全相同的审查逐渐浮出来的。
所以 skill review 和多轮 review 不是同一种东西。
skill 更像审查框架，负责定义“应该看哪些方向”；多轮 review 更像置信度策略，负责提高“真的看到问题”的概率。前者解决覆盖面，后者解决召回率。
更合理的做法可能是把两者叠在一起：
- 先用 skill 固定审查维度，避免每次都凭感觉问
- 再做多轮独立 review，让 AI 每轮只关注一类风险
- 每轮要求输出“高风险问题、低风险问题、未能判断的问题”
- 最后再做一次合并，把重复问题、真实问题和误报区分开
这也意味着，workflow 不应该迷信“有一个 review skill 就够了”。skill 可以让审查更有章法，但多轮审查仍然有必要。尤其在自己不熟悉的领域里，一次 review 通过并不等于风险已经消失，它只能说明这一轮没有发现足够明确的问题。
人工 review 是最后闸门#
还有一个更基础的原则：用 AI 一定要人工 review，尤其是在它拥有较高权限、能够自动读写文件、执行命令、提交代码、调用接口的时候。
高权限和自动化本身不是问题，它们也是 agent 能真正完成任务的原因。但这两者叠在一起，会把错误的放大速度变得很快。一个没有人工闸门的 agent，可能不是帮手，而是自动闯祸机：它可以很快改错文件、删错逻辑、提交错误代码，甚至把一个没有被理解的方案推到远端。
人工 review 的意义不只是“再看一眼代码”。它至少要确认几件事：
- 这次改动是否真的对应当前需求
- AI 有没有顺手改掉不该改的地方
- 关键业务规则是否被正确表达
- 权限、数据、状态和错误处理是否有明显漏洞
- 验证结果是否足以支撑这次交付
- commit 里是否混入无关改动
这也是为什么自动化越强，越不能把最后一步也完全交出去。AI 可以生成、修改、解释、审查，但“这次可以交付”的责任仍然需要人来承担。至少在当前阶段，人工 review 是 AI 开发流程里的最后一道闸门，而不是可选项。
短工期下的风险优先模式#
如果把这个思路收束成一个更适合短工期的 workflow，它大概不是完整的“需求、调研、计划、任务、日志”，而是下面这样：
1. Triage：先判断风险等级#
不是所有需求都需要同等流程。只要涉及权限、支付、状态流转、批量写入、数据迁移、第三方回调、异步任务、消息队列，就应该自动标记为高风险。
低风险需求可以轻量处理。高风险需求即使工期短，也不能跳过风险审查。
2. Scope Lock：先锁范围#
短工期里最危险的事情之一是边做边扩。范围一扩，验证面也会扩，但验证时间通常不会跟着增加。
所以一开始要明确三件事：本次必须交付什么，本次明确不做什么，哪些地方只做兼容或兜底。
3. Risk First Plan：先列风险，再写方案#
传统 plan 经常先写“怎么实现”。风险优先模式应该反过来：先列出最重要的风险，再让方案逐条回应这些风险。
如果一个方案说不清楚权限、数据一致性、失败恢复和日志，那么它还不是可交付方案，只是实现草图。
4. Contract Before Code：先确定契约#
对不熟悉后端的人来说，接口契约、数据字段、状态枚举、错误返回和权限规则，往往比具体代码更重要。
代码可以由 AI 快速生成，但契约一旦含糊，后面的实现会在含糊处不断分叉。先锁契约，至少能让 review 有明确对象。
5. Implement Small：只实现最小闭环#
短工期不是展示抽象能力的时候。能不重构就不重构，能不引入新依赖就不引入，能不设计通用框架就不设计通用框架。
实现越小，review 和验证越可能完成。
6. Review Drill：实现后独立审查#
实现完成后，需要让 AI 切换为 reviewer，而不是继续沿着实现者的叙事往下走。
比较有效的问法不是“检查一下有没有问题”，而是：
请假设这个实现已经上线并发生严重事故，列出最可能的 5 个原因。请从资深后端 reviewer 的角度审查这段改动，重点关注权限、数据一致性、并发、幂等、错误处理和可观测性。请找出这个实现里哪些判断只存在于代码层，哪些应该下沉到数据库约束、事务或唯一索引。这种 review 不保证发现所有问题，但它会迫使方案从“能跑”转向“坏了以后能否解释”。
7. Evidence：交付证据，而不是交付信心#
最后交付时，不应该只说“已完成”。更有价值的是留下证据：
- 跑了哪些测试
- 手动验证了哪些路径
- 哪些风险被处理了
- 哪些风险只是被接受了
- 如果后续要优化，最应该看哪里
这一步的意义不是写漂亮总结，而是把“我觉得可以”变成“我验证过这些，所以暂时可以”。
同时，一轮 commit 或 push 应该对应某一块明确功能的实现，而不是把多个不相关的修改混在一起。混乱的提交会让 review、回滚和问题定位都变困难。短工期里尤其容易把“顺手修一下”“顺手重构一下”“顺手调整一下配置”塞进同一次提交，但这会把交付风险藏起来。
更好的提交粒度是：一个 commit 能说清它解决了哪一个问题，影响了哪些文件，如何验证。如果说不清，这一轮改动就可能已经超过了可控范围。
AI 的角色需要被拆开#
AI 辅助开发里，一个常见问题是同一个 AI 从需求理解、方案设计、代码实现一路做到自我检查。它会天然维护自己的叙事连续性。前面做了某个假设，后面往往会顺着这个假设继续补完，而不是主动拆掉它。
更稳的方式是把 AI 角色拆开：
- 实现者：负责实现最小闭环
- 审查者：负责挑错和找风险
- 运维视角：负责从上线、日志、回滚、事故处理角度审查
- 业务追问者：负责追问业务规则是否完整
即使实际使用的是同一个模型，也应该在 prompt 上强制切换角色。尤其在自己不熟悉的后端领域里，审查者和运维视角的价值可能比实现者更高。
因为真正降低风险的不是“写得更快”，而是“更早发现哪里不能信”。
最后回到学习问题#
这件事最后还是会回到学习。不能永远靠 AI 审 AI，也不能把所有风险都交给流程。但学习不一定意味着先脱产补完整个后端体系，再回来做项目。
更现实的方式是按项目补能力。每个项目只刻意抓一个后端主题：这次重点看权限，下次重点看事务和索引，再下次重点看异步任务和幂等。项目提供真实问题，学习提供判断框架，两者需要互相咬合。
从这个角度看，短工期下的目标不是建立一个完美的优化循环，而是建立一个最低限度可靠的交付循环：
先识别风险，再收窄范围；先锁契约，再写代码；先独立审查，再交付证据。
这可能是我现阶段更需要的 AI 开发方式。不是让 AI 替我假装懂后端，而是让 AI 帮我暴露自己还不懂什么，并把这些不懂的部分转化成可检查、可验证、可逐步补上的工程问题。