118个API塞进1个文件，开发者把他们的"成功复盘"扒了个底朝

一个工程师读完某团队的AI开发复盘博客，甩了句狠话：「这玩意儿跟CIA的情报史一个路数——专门让自己看起来不可或缺，哪怕根本不是那么回事。」

写博客的产品经理愣了一下，然后承认：他说得对。

「成功剧场」的观众只有一个人

Nick Pelling，资深嵌入式工程师，跟踪观察这个AI托管开发项目已经有一段时间。团队发了9篇冲刺复盘，他逐条挑刺：

「博客的成功剧场只有一个观众。」

「记录活动是给利益相关者看的，对非利益相关者没什么意思。」

「也许你们需要第二个博客，写点其他人真正想看的内容。」

他戳破了一个尴尬的事实：团队把内部问责文档包装成开发者内容发了出去。那些帖子本质是审计日志，套了层博客的皮。

看看他们Sprint 7复盘里的原话：

「连续9个冲刺发布通过——100%可靠性保持。」

数字是真的。但问题是，这是写给老板看的进度汇报。Dev.to上的开发者读到这行，内心OS大概是：「所以呢？跟我有什么关系？」

还有这种：「OAS-124-T2：流水线执行与产物验证——7项测试通过。」

ticket ID都端上来了。外人根本不知道OAS-124是什么。团队在自说自话，却假装在跟读者对话。

118个服务，1个文件，0个运行时测试

这个团队在做的东西其实挺有意思：一个AI托管的「营销机构」，自动完成内容采集、脚本生成、音频旁白、视频制作和发布。Sprint 7的目标是证明所有模块能协同工作。

他们确实干了活——6个冲刺里建了118个后端服务，从文本转语音到YouTube上传，每个都单独测过，运行正常。

然后他们把这118个路由全塞进了一个Express服务器文件（api-server.mjs）。没有领域分离，没有路由模块，118个接口，一个文件。

这种决策当时看着很务实（「先加到server文件里」），但别人一读代码就变成了技术债。团队承诺在写前端代码之前先把路由模块拆出来，但能让它走到这一步，本身就是规划失误。

Sprint 7的「重大成果」是「118个服务接入生产REST路由」。听着挺唬人。

但看看他们的测试到底在测什么：

// 实际测试内容（源码检查）

const src = fs.readFileSync('api-server.mjs', 'utf-8');

expect(src).toContain('app.post("/api/memory/store"');

// ✅ 通过——路由注册确实写在源码里了

// 没测的内容（运行时验证）

const res = await fetch('http://localhost:3847/api/memory/store', {

method: 'POST', body: JSON.stringify({ content: 'test' })

expect(res.status).toBe(200);

// ❌ 这种测试他们根本没写

测试只检查「代码里有没有这行字」，不检查「接口能不能跑」。这是典型的「看起来测了」vs「真的测了」的区别。

复盘博客成了自我安慰剂

9篇帖子，模式高度一致：罗列完成的功能、通过的测试、达到的里程碑。数字都是真的，但叙事角度完全内倾。

一个外部开发者想从这些帖子里获得什么？可能是技术选型的得失，可能是架构决策的反思，可能是踩坑的具体细节。但这些帖子里，决策过程被压缩成一行结论，踩坑经历被包装成「已解决」，技术债务被轻描淡写为「后续优化」。

Pelling的批评之所以扎心，是因为它指向一个更普遍的陷阱：把「记录我们做了什么」当成「分享有价值的内容」。前者是项目管理，后者是知识传播，两套逻辑，硬缝在一起。

团队现在面临的选择是：要不要开第二条线？一条继续给内部 stakeholder 看进度，另一条写给真正的技术读者——讲清楚为什么把118个路由塞进一个文件，当时怎么想的，后来为什么后悔，拆模块的时候遇到什么具体麻烦。

这种内容没有100%可靠性可以汇报，但可能有人愿意读。

他们的AI营销机构项目还在跑。第10篇复盘会怎么写，现在是个开放问题——是继续「成功剧场」，还是试试别的剧本？