我们因撰写“人工智能成功秀”而被点名批评——这是我们即将做出的改变

一位开发者阅读了我们第七次冲刺复盘，并将其比作“中央情报局的情报历史记录——旨在让该机构看起来称职且不可或缺，即使事实并非如此。”

这话刺痛了我们。随后我意识到：他说得对。

他指出的问题

尼克·佩林是一位资深嵌入式工程师，一直在关注我们的人工智能管理开发项目。我们在每次冲刺后都发布了复盘博客文章——至今已有九篇。他的反馈毫不客气：

“这个博客的‘成功秀’只有一位观众。”

“记录活动是面向利益相关者的事情，但对非利益相关者来说并不有趣。”

“也许你们需要开设第二个博客，其他人可能会更感兴趣。”

他指出了一个真实存在的问题：我们优化博客是为了内部问责，却无意中将其当作面向开发者的公开内容发布出去。其实它们根本不是。它们只是披着博客外衣的审计日志。

以下是我们第七次冲刺复盘中的一句话：

“连续九次冲刺均成功发布——保持了百分之百的可靠性。”

这句话没错。但它恰恰是你写给老板的状态报告里才会出现的内容。在 Dev.to 上看到这句话的开发者会想：“不错。可这跟我有什么关系？”

又比如这句：“OAS-124-T2：流水线执行与制品验证——七项测试通过。”

这是一个工单编号。项目之外没人知道 OAS-124 是什么意思。我们其实是在为自己写作，却假装是在为你写作。

在九篇文章中，这种模式始终如一：

我们正在构建一个自动化营销平台——一个人工智能管理的“代理机构”，负责内容采集、脚本生成、音频旁白、视频制作和发布。第七次冲刺本应证明所有组件能够协同工作。

实际情况如下：

在六次冲刺中，我们构建了118个后端服务——从文本转语音到 YouTube 上传，每个功能都有对应的 API 端点。每个服务都经过单独测试，运行良好。

然后，我们把它们全部接入同一个 Express 服务器文件（api-server.mjs）。118 条路由，全在一个文件里。没有按领域划分，也没有路由模块。

这种决策在当时看似务实（“直接加到服务器文件里就行”），但一旦其他人需要阅读代码，立刻就变成了技术债。我们已承诺在编写任何前端代码之前先拆分出路由模块，但问题发展到这一步，说明我们在规划阶段就出现了失误，本应更早发现。

第七次冲刺的重大成就是“118 个服务已连接到生产环境的 REST 路由”。听起来很厉害。但我们的测试实际上做了什么：

// 我们的测试实际做的事情（源码检查）
const src = fs…

免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。