我把 AI 当新员工管：3 小时交付 10853 行代码的工程复盘
2026 年 4 月，我让 Claude Code 实现一个 Go + Gin 的定时任务 MCP Server。
我把 AI 当新员工管：3 小时交付 10853 行代码的工程复盘
原创：朱志勇 · AI 落地陪跑营 阅读时间：约 12 分钟 适合人群：用 AI 写代码 1-2 年、被「上下文丢失 / 规范不统一 / 质量飘忽」困扰过的开发者
一、一次让我想砸键盘的「AI 失忆」现场
2026 年 4 月，我让 Claude Code 实现一个 Go + Gin 的定时任务 MCP Server。
目标 9 个 Tool：CRUD + 暂停恢复 + 执行记录 + 回调幂等。 技术栈：Go 1.22 + Gin + GORM + Redis + robfig/cron。 预估工作量：3-5 天人工。
我开了个新会话，把 PRD 贴进去，Claude Code 给我输出了 200 行漂亮的代码。
然后我切到下个任务，开了个新会话。
新会话的 AI 看着我之前写的代码，问：
「这项目的分层规范是什么？」 「错误码用什么命名空间？」 「DTO 字段更新是用指针还是值类型？」
它全忘了。 而且我也没写下来。
我花了 30 分钟口述规范，AI 点头说「明白了」。再过一会，又忘了。
那天晚上我盯着屏幕想——
这不是 AI 的问题。
这是「我」的问题。
我把 AI 当成了「工具」——但工具不会失忆；把 AI 当成「员工」——员工会。但员工有公司、有规范、有流程、有工位。
如果我给 AI 配齐这些，它是不是就不失忆了？
这就是 AIES（AI Engineering Scaffold）的起点。
二、AI 不是工具，是新员工
这个类比改变了一切。
| 真实员工 | AI Agent | 我需要做的 |
|---|---|---|
| 员工手册 | .aies/spec/ | 写架构 / 代码风格 / 错误处理规范 |
| 工位 | .aies/.ai/ | 写项目地图（哪些函数、哪些接口真实存在） |
| 工单 | .aies/tasks/{slug}/prd.md | 每个任务必须有 PRD |
| 验收标准 | .aies/tasks/{slug}/acceptance.md | 每个任务必须有 P0 场景 |
| 工时日志 | .aies/workspace/{dev}/journal.md | AI 记录每个决策的「为什么」 |
| 上下级签字 | git commit/push 必须人点头 | 防止 AI 自主乱提交 |
| 季度复盘 | Spec 回流（每次任务后） | 把踩坑写进 spec，下个项目自动规避 |
AI 不是工具，是员工。 员工会失忆、会偷懒、会编造——但你不会因此开除员工，你会给它建制度。
AIES 就是给 AI 员工建的制度。
三、3 小时 10853 行代码的真实战例
我先用战例证明这套制度有效，再说设计。
3.1 任务背景
业务平台的智能体系统需要一个「闹钟模块」：AI Agent 通过自然语言创建定时推送任务，到期自动触发后续操作。
技术要求：
- 9 个 MCP Tool（CRUD + 暂停/恢复 + 执行记录 + 回调幂等）
- 双调度模式：
time.AfterFunc（一次性）+robfig/cron（周期） - 多实例部署防重复触发（Redis 分布式锁）
- GA 执行结果追踪（HTTP 回调 + 幂等）
3.2 工程状态
基础设施层（config / middleware / pkg）已有。
业务代码全部缺失：
- ❌ entity 层（无 GORM 模型）
- ❌ model/DAO 层
- ❌ MCP Server
- ❌ Service 层
- ❌ 调度引擎、执行引擎
- ❌ router / handler / main.go
3.3 跑 AIES 的结果
3 小时。 97 个文件。 10853 行代码。 20 个 P0 验收场景全过。
人工介入 3 次：
- 提供 MySQL / Redis 连接信息（30 秒）
- 说「ok」确认 Spec 回流写入（5 秒）
- 说「ok」确认 git commit（5 秒）
总输入字数 < 200 字。
Bug 自主修复 2 个：
- GORM varchar 推断错误 → 修复后自动沉淀进 quality-gates.md
- executor context 超时 → 修复后写进 journal.md 解释「为什么用 5 分钟 context」
3.4 关键不是 3 小时
关键是 3 个月后再看这段代码，我依然知道为什么这样写。
journal.md 里有：
为什么 executor 的 goroutine 用 5 分钟 context：
- HTTP 单次超时 30s
- max_retry=3，总重试时间最多 1+2+4=7s
- 总耗时 < 45s，但与 context 30s timeout 叠加后超界
- 结论：goroutine context 不是「单次 HTTP 超时」，是「整个重试链的存活保障」
3 个月后看到 5 * time.Minute，我知道为什么不是 30s、不是 1 分钟——是 5 分钟。
这不是 AI 写代码，这是 AI + 制度写代码。
四、AIES 的 5 大设计原则
我把 7 个落地项目（AI-course-studio、Ymb-agent 6 子工程、Msg-collect、thirdspace-video-pipeline 等）的踩坑汇总成 5 条原则。
原则 1：Spec 在仓库，生效在平台
问题：Claude Code / Cursor / Copilot / Codex 各自有自己的配置文件（CLAUDE.md / .cursorrules / AGENTS.md），规范写 5 份 = 5 处不一致。
解决：
.aies/spec/ ← 所有编码规范只写一份
.aies/.ai/ ← 项目实例信息只写一份
平台入口文件: ← 只引用，不重复内容
- Claude Code: CLAUDE.md
- Cursor: .cursorrules
- Copilot: .github/copilot-instructions.md
- Codex: AGENTS.md
改一份 spec，5 个平台同时生效。
真实效果：Ymb-agent 的 6 个子工程，desktop-shell 跑 Claude Code，profile-engine 跑 Cursor，script-library-engine 跑 Codex，3 个平台用同一份 spec——一致性自动保证。
原则 2：渐进式上下文
问题：项目多了，spec 文件几十个，AI 启动时全量加载 = 50K token 浪费。
解决：每个任务有 context.jsonl，只列本任务需要的 spec：
{"phase": "implement", "spec": "architecture.md", "reason": "理解分层约束"} {"phase": "implement", "spec": "code-style.md", "reason": "命名和格式规范"}
AI 只读 architecture.md + code-style.md，不读 guides/ 下所有 4 个文件。
真实效果：3 小时 agent-crontask 任务中，整个实现过程中 spec 被引用 6 次以上，但每次只读需要的。
原则 3：默认单 Agent，按需多 Agent
问题：很多 AI 协作框架上来就搞「多 Agent 编排」，为多而多。
AIES 立场：
- 绝大多数场景单 Agent + Spec + 清单就够用
- 多 Agent 仅用于长耗时 / 高复杂度任务
- 何时用多 Agent 写进
docs/multi-agent-decision.md
真实效果：Ymb-agent 的 20+ P0 任务，只有 desktop-shell 用了 4 个 agent 并行（License / Worker Manager / Workflow / MVP），其他 5 个子工程都是单 Agent。
原则 4：人是质量门最后一道
问题：AI 自我评估 = 自己说自己做得不错。
AIES 立场：
- AI 自检是第一道（check.md 8 维度 review）
review-checklist.md必须由人过一遍- git commit/push 必须人明确说"提交"
真实效果：3 小时的 agent-crontask 任务，人工只介入 3 次——但这 3 次是关键决策点（连接信息、Spec 回流确认、提交）。其余 99% 的代码、AI 自主完成。
原则 5：方法论 > 工具
问题：很多人把 AIES 当成「装个脚手架就完事」。
AIES 立场：
脚手架是方法论的载体，不是魔法盒子。请先读
docs/philosophy.md。
真实效果：每个用 AIES 的项目必须先读 philosophy.md——理解「为什么这样做」比「做什么」重要。
五、3 条铁律（AGENTS.md 强制）
AIES 写入 .aies/AGENTS.md 的 3 条不可违反的规则：
铁律 1：禁止编造
任何函数、类型、接口，先读
.aies/.ai/index.md确认真实存在。
为什么重要：AI 最常见的错误是编造不存在的 API——subgraphs.shared.llm.llm_minimax()，但这个函数从来没在 index.md 里登记过。
怎么强制：index.md 是项目真实存在的接口清单，AI 写代码前必须先搜。
铁律 2：禁止沉默跳过
Phase 3 Spec 回流三问，必须显式回答。
Q1: 本次有没有"应该统一规范"的地方？[有/无] Q2: 有没有踩坑，下次需要提前规避？[有/无] Q3: spec/guides/ 是否需要新增场景？[有/无]
为什么重要：AI 偷懒时会说「无新约定」——但实际上可能有。禁止沉默跳过 = 禁止"我觉得没事"。
铁律 3：禁止未确认提交
git commit/push需要用户明确说"提交"。
为什么重要：AI 不会审「这次提交是否合理」——人必须拍板。
六、8 维度 Review Checklist
AIES 的 spec/quality-gates.md 配套一份 465 行的 review-checklist——AI 写完代码必须自检的 8 个维度：
| 维度 | 关键检查项 |
|---|---|
| 架构合规 | 分层 / 依赖方向 / Context 透传 |
| 数据安全 | SQL 注入 / 越权 / 敏感信息 / 输入校验 |
| 数据完整性 | 事务 / 级联 / 唯一约束 / 外键 |
| 边界条件 | 空值 / 超大输入 / 重复 / 并发 / 零值陷阱 |
| 错误处理 | 分类 / 含义 / 不被忽略 / 错误码 |
| 性能 | N+1 / 预加载 / 分页 / 索引 / 缓存 |
| 日志 | 关键操作 / 错误 / 敏感 / 级别 / trace id |
| AI 盲区 | 硬编码 / 默认值 / 时区 / 编码 / 单位 |
为什么这 8 维度？因为这是 AI 写代码最常翻车的 8 个地方——不是「测试通过就行」，是「这 8 个地方都过了才放心」。
七、AIES 不解决的事（诚实声明）
AIES 是协作操作系统，不是银弹。
它不解决：
- 线上监控 Dashboard——acceptance.md 是项目级一次性，没有持续 Eval Pipeline
- LLM 成本优化——没有 token 统计 + 成本看板
- 多租户隔离——设计上是单开发者单项目
- 公开影响力——AIES 还没开源到 GitHub
这 4 个是我接下来 90 天的补课清单（如果你感兴趣，下次专门写一篇）。
八、给读者的 3 步上手
如果你也想用 AIES 思路管理你的 AI 协作，今天就能做这 3 步：
第 1 步：写项目地图（30 分钟）
在项目根建 .ai/index.md，列出真实存在的：
- 模块结构（哪个目录干什么）
- 关键函数 / 类型
- 跨模块调用关系
第 2 步：写最关键的 3 份 Spec（1 小时）
不要试图一次写完。只写最常翻车的 3 个：
architecture.md（分层约束）code-style.md（命名 + 格式）quality-gates.md（禁止 / 必须模式）
第 3 步：每次 AI 任务后做 Spec 回流（5 分钟）
3 个问：
- Q1 这次有没有新约定？
- Q2 这次有没有踩坑？
- Q3 这次需不需要新 guide？
3 个月后你会回来感谢现在的自己。
九、附录：3 个真实战例速览
| 战例 | 时长 | 产出 | 人工介入 |
|---|---|---|---|
| agent-crontask（Go + Gin + Redis） | 3h | 97 文件 / 10853 行 / 20 P0 全过 | 3 次 |
| Ymb-agent 6 子工程并行 | 持续 | 20+ P0 任务 confirmed | 极低 |
| ai-course-studio | 1 月+ | 10 个 AIES 任务 / 已落地 | 正常 |
十、彩蛋：3 个钩子问答
如果你正在面试 AI Engineer 岗，面试官问「你的 Harness 怎么设计」，你可以讲这 3 句话：
- 「AI 不是工具，是新员工——AIES 就是给新员工建的制度」
- 「我在 7 个项目跑过这套制度，最牛的一次是 3 小时交付 10853 行 Go 代码，人工介入 3 次」
- 「制度的核心是 3 条铁律 + 8 维度 review + Spec 回流知识飞轮」
讲完这三句，面试官会记住你。
关于作者：朱志勇 · AI 落地陪跑营主理人 · 5+ 年 AI 工程经验，自研 AIES 框架，已在 7 个项目落地。
AIES 完整代码：计划本月开源到 GitHub（zzyong24/ai-engineering-scaffold），先到先得——点赞 + 在看， 公众号后台回复「AIES」加入内测群，开源后第一时间通知。
本文为 AIES 设计理念上篇，下篇写「如何用 AIES 的 8 维度 review 自检你自己写的代码」，敬请期待。
如果觉得有用，转发给那个「用 AI 写代码但总失忆」的同事。
他们需要这份「员工手册」。 👇
