公开版 · 业务细节已泛化，部分例子已改写

人定义「对」，
AI 跑到「对」

553
个 AI 会话
6480
条我亲手打的消息
69
个活跃天（8–10 月）

一个后台开发三个月用 AI 写真实需求的复盘 · 厉辉 yousa

开始前

先举个手：你同意吗？

AI 写完、测试跑通，就算完成了

0人举手

让 AI 自己 review 自己，就够了

0人举手

常听到的两种说法。答案留到最后。

我是怎么用的

三个月，几乎每个工作日都在用

8 月9 月10 月

每格一天，颜色越深，当天会话越多

8
个会话 / 活跃天
23
最忙一天（10 月初）
4
份代码副本，各跑一个不相干的需求
代码副本git worktree，同一仓库的几个独立工作目录

互动 · 一次资源池扩容推算（已改写）

AI 的这段推算，哪几句有出处？

AI 原话大意。一个前提是猜的，后面整串推算都是猜的。做法：让它给每个数字标出处，标不出的当假设。

只讲这一个问题

这一步的「对」，机器能不能自己检查？

能检查交给 AI 循环，跑到通过
0
不能人拍板
0

能 → 交给 AI 循环，
跑到检查通过。

不能 → 人拍板，
或者变成能检查的。

人定义「对」，AI 跑到「对」。

变成能检查的

打回 打回 实现 修复 已合入 测试 点击拔掉 审查 点击拔掉

循环长什么样 · 示意

一条指令，让它自己转到通过

实现代码，tdd 的方式实现。实现完成后，补充单元测试，verify，使用多个 review skill review 代码，修复发现的问题

方块是一次改动，红标是缺陷。闸门拦下的落到这里

测试×逻辑错!边界漏判
审查»越界改动?需求外行为
闸门（数字均为示意）跑了几轮漏到已合入
测试 + 审查——
只有测试——
没有闸门——

tdd先写测试，写到测试通过verify让它对照 spec 逐条自查review skill写好的审查规则，一份 markdown

地图 · 这三个月 · 示意

循环能跑多远，取决于哪几段变成了检查

– 本月人要
停下几次 掉出 1 个
任务包

打通：自己流过 部分自动：挤过去 人工闸门：停下等人 缺口：没人看 点任一段看详情

能检查的

把说法变成能跑的测试，才交给循环

9 月初 · AI 报告「某个条件下列表会空白，影响面很大」，准备修。这段逻辑我自己验过是好的。

「这是一个非常具体的 bug 吗？可以在单测里复现出来吗？」

「bug 的原因到底是什么，能不能用两三句话跟我讲清楚？」

后来写进流程规则（9 月底）：
每个修复先写能复现问题的测试，再改代码

这两句新人第一天就能问。
问出来的，就是你的价值。

但检查本身靠得住吗

检查会被糊弄

8 月底 · 端到端验证 · 这个接口通了吗？

HTTP 200

retCode = 0

列表：[]

日志：请求打到对端

日志：对端返回 401

日志：服务静默降级成空列表

假绿

10 月初 · 审查 AI 被理由说服

需求只写了时间范围，AI 自己加了条数上限。审查 AI 看了设计文档里的理由，反而建议给上限加告警。

后来加的「反向追溯」：

开一个只拿到需求原文和 spec 的 subagent，任务只有一个：列出 spec 里所有从需求原文推不出来的行为。不要给它设计文档，否则它会被理由说服。
MCP让 AI 能直接调用日志平台、数据库等工具subagent主 AI 另起的独立 AI，只看你给它的材料

也会漏 · 定时提醒半夜推送

漏到线上的一次

这个定时任务是 AI 写、我合进去的。注释看着很笃定，AI CR 也没发现。

下午开跑傍晚0 点凌晨
修复前
推到后半夜
热更后
当天下午结束

过了零点，当天的「已完成」标记过期，已完成的人也被提醒

谁发现的

用户半夜收到提醒，反馈回来才知道。不是我的检查发现的。

为什么没拦住

这个任务当时没有灰度，一上线就是全量；当时运行时长没有监控。

补了什么

串行读改批量。

热更不跟常规版本，单独紧急发布灰度先放一小部分用户到新逻辑

所以

我现在守的几件事

合入前有 AI CR，但它不一定能发现问题；再加只读 AI 审查 + 提交前范围检查。合入是我点的。
上线前测试验收 + 灰度 + 留回滚窗口。
上线后运行时长监控 当时缺，提醒就漏在这

三个月里能从会话查到 7 件事：6 件拦在合入或上线前，1 件漏到线上。

每漏一次，补一道检查 · 9 月底 → 10 月初

第二次纠正，就做成 skill

「这个模块不是我负责的。我这次的修改应该只局限于我要修改的范围。」

9 月底，AI 顺手改了别的模块的一个时间戳比较。十天后做成「改动范围审计」skill。

发现 ≠ 决定。一处改动能不能进这次提交，只看两件事：用户有没有明确要过它，被改的东西归不归用户管。
A 目标内提交
B 必需但动了别人的停下来问
C 顺带还原，记入移交清单
D 来源不明还原

auditing-change-scope/SKILL.md 摘录

这样的 skill，三个月写了七个

每一道检查，都对应一次手动纠正

8 月9 月10 月
字段对齐「不应该完全由自己凭空去造」8 月初
过度设计审查「代码太多反倒是难以维护」8 月初
配置开关审查先只看 key 名猜行为8 月中
注释减法「最多 1-2 行注释」9 月初
先定约束再出方案「为什么会有不同的选择？」9 月初
改动范围审计「这个模块不是我负责的」10 月初
兼容性盘点「以后方案定稿和提交前都能跑」10 月底

互动 · 一个通知类需求（已改写）

哪几项是 AI 推断出来的？

需求原文

新增通知文案：必填，长度有上限

一次批量操作时，依次提到本次涉及的人 + 文案

AI 梳理需求时列出的 4 项（点选你认为是推断的）

需求也能变成检查

台账：每一行行为都要有出处

#行为出处
B6文字超长时报错原文写了长度上限；我确认 D5
B22一条通知提到的人数不设上限我确认 D3
Q12防刷、去重、重试、告警、兜底加法：原文没要求，默认不做

双盲：两个互相看不见的 AI，只读需求原文，各自列出「没定死、读法不同做出来就不同」的地方。

合并规则：两份选得一样也照列，一致只说明两个模型想到一块去了。

有一次：两个 AI 都选「关闭时不清理数据」。

「关闭时，确实需要清理数据，否则会有问题。」

我定的 D4 · 两个 AI 一致，人推翻了

台账每个需求一份 markdown，出处只有三种：原文 / 我确认 / 按默认未确认双盲两个互不可见的 AI 分别读同一份需求

变不成检查的

意图、范围、能不能回退，人来守

意图 · 10 月底

客户端问：入口接口没返回这一项，还要不要调详情？AI 从代码看不出来：详情只在用户点了按钮或弹窗后才调。代码里读不出来的意图，要人补进文档。

回退 · 9 月初 · 同一个问题，答案取决于能不能回退

「尽量少改、不要删，我们只需要新增。加一个 v2 切到新的逻辑上，这样更可控一点。」

D4 我能推翻，是因为我知道不清理数据会出问题。新人不知道的时候，你的活就是把这一项问出来。

回到开场

再看那两张卡

AI 写完、测试跑通，就算完成了

0 人举手

回包 200 也可能是假绿

不看它说的，看日志和实测。

让 AI 自己 review 自己，就够了

0 人举手

审查 AI 会被理由说服，两个 AI 一致也会错

我也用 AI 审查，但结论要对上需求原文、已有代码或真实运行。合入是我点的。

带走

各自带走什么

新人：第一周三件事

  1. 修 bug 先让 AI 写能复现的单测，再问那两句
  2. 接需求让 AI 把「写了的 / 推断的」分两列，推断的拿去问 带你的人
  3. 提交前看一遍 git diff：改到别人目录的、需求里找不到的，先撤掉单独提

「定义对」AI 拿不走。新人的价值就是问清楚、写下来。

资深：团队落地

  • 能直接给组里用：改动范围审计、过度设计审查
  • 兼容性盘点只适用特定代码库，带走它那张清单
  • 成本：token 和钱我还没算过

AI 重度用户：防糊弄

  • 审查 AI 只读、只出问题不改代码
  • 反向追溯不给设计文档
  • 不认同的 finding 写理由驳回，不为清空列表改代码

最后

这一步的「对」，
机器能不能自己检查？

需求原文 — 让它把推断列出来，问清楚再做

已有代码 — 不是你的模块，这次不改

真实运行 — 不看回包，看日志和实测

AI 让「写出来」几乎免费，贵的是「什么算对」。

附录 · 讲后翻看 · 这页是立正的提炼，不是本场原创

第一性原理：先问产品，再查价格表

一、先把 AI 放到一边

这项工作交付的到底是什么？以数据分析为例：

SQLDashboard模型

产品是更好的决策

所以先看决策变没变。分析快了十倍，组织还是不知道下一步做什么，那只是更快地生产了中间品。

认清产品，才分得清哪些做法来自事情本身，哪些只是在补偿当年的限制。

二、每套 best practice 背后，都藏着一张当时的价格表

代码贵所以尽量复用 观测全貌贵所以只能抽样 执行贵所以行动前多开会、多交接

约束一消失，围绕它的做法就要重新证明自己。

一次性软件：查一批重标数据，AI 两分钟搭出对比网站，十分钟看完全部改动，只退回错得多的场景。网站扔掉，判断留下。适用：一次性的小需求，且错判比造工具贵。

和本次的连接：AI 让「写出来」几乎免费，贵的是「什么算对」。

出处：立正《到底什么才算 AI Native 人才？》2026-08-13；一次性软件案例来自鸭哥（Yan Wang）。

附录 · 讲后翻看 · 观点来自立正和鸭哥，右栏才是本场的东西

四条 mindset，和本次对得上的地方

结论
补上的逻辑
本次在哪出现过

从过程确定性到结果确定性

double-check → cross-check

路径可以变，结果要经得起验证。double-check 是同一思路再做一遍；cross-check 换路径：测行为、查不变量、比两条实现。高风险操作仍要过程约束。
对上需求原文、代码、真实运行。双盲两个 AI 一致，仍被 D4 推翻：同源不等于独立。

先删除，再自动化

减法要人来做

fake work：用可见的动作，代替难以衡量的价值。AI 不替你纠正目标，通常先把现有目标做得更便宜，没用的活反而更难死。测法：一路追问「然后呢」，直到碰到真实变化。
过度设计审查、改动范围审计。台账 Q12 标「加法」：原文没要求，默认不做。

More agents ≠ more intelligence

一个判断，一条主线，一个 owner

开子代理前三问：一小段输入能定义完吗？输出能独立验收吗？并行的收益大于复制上下文和重新综合的成本吗？都接近「是」才开。五个相似的 Agent 可能只是同一平均值采样五次。
合入是我点的。反向追溯过得了前两问：只给原文和 spec，只出清单。第三问答不了：成本没算过。

管理 AI 是一次晋升

专家最难的是 unlearn

从亲手做出每个结果，到让系统持续出好结果；专业能力移到定义工作、判断风险、建立验收。unlearn 是拆开：留下现实教出来的判断，旧约束留下的动作重新检验。
人定义「对」，AI 跑到「对」。9 月初 那个问题：答案看此刻能不能回退，不凭习惯。

出处：立正《到底什么才算 AI Native 人才？》《如何识别与消灭 fake work》《More agents 不等于 more intelligence》，2026-08；结果确定性、管理 AI 两条的原文作者是鸭哥。「四条」是转述时的归纳。