Claude Code 真的能替我写完那个烂需求吗

Claude Code 真的能替我写完那个烂需求吗

昨天下午三点，产品经理把需求文档甩群里——要给后台管理系统加个「智能导入」功能，支持 Excel、CSV、JSON 三种格式，还得自动识别表头映射字段，容错率要 99% 以上。我看了眼日历，下周三上线。

说实话，要是半年前我得通宵两晚。现在我先打开终端，敲了行 claude-code --version，返回 1.0.47，比上周更新了两个小版本，修了个 Windows 下路径解析的坑。

然后我把需求文档拖进去，没写 prompt，就丢了一句：「帮我实现这个导入功能，代码规范按组里现有的 eslint 配置来。」

三分钟不到，终端刷出一堆文件。我瞄了眼结构：src/utils/import/parser.ts、validator.ts、mapper.ts、index.ts，还顺手生成了单测，覆盖率 92%。

有意思的是它没用 xlsx 那个大家都用的库，改用 sheetjs 的社区版，理由写在注释里：xlsx 0.18.5 版本对大文件内存泄漏，sheetjs 0.2.1 已修复，见 issue #1423。我去 GitHub 确认了一下，确实是去年 11 月修的，合并进主分支才两周。

但我没直接跑测试。先把生成的 parser.ts 拉下来，塞进我们项目的 ImportService 里，改了两处类型定义——我们的 FieldMap 接口比它生成的多个 transformFn 字段，用于处理日期格式转换。跑一下单测，有 3 个失败，全是边界情况：空文件、只有表头没数据、字段名重复。

我补了这三个 case，再跑一遍，全绿。

中间有个小插曲。生成的 validator.ts 里用了 zod 做 schema 校验，但我们项目锁死 joi@17.9.2，升级成本太高。我跟它说：「把 zod 换成 joi，保持同等校验能力。」它愣了两秒，把整个文件重写了，连错误信息格式都对齐了我们现有的 ValidationError 类。

事后想来，要是换 Cursor 的 Composer，大概率会给我装个 zod 依赖，再让我手动改 package.json。这点上 Claude Code 确实懂「上下文」——它读了整个 package.json 和 tsconfig.json，知道不能动锁死的依赖。

不过也翻车过。上周四有个需求要对接三方支付回调，文档写得跟屎一样，字段名驼峰下划线混用，金额单位一会儿分一会儿元。我把文档扔给它，让它生成适配层。结果它按文档字面意思写了，上线后回调全挂——对方实际发的是字符串金额，文档写的 number。

我改了 mapper.ts 里一行，加了 Number() 转换，顺手在注释里骂了一句：// 三方文档不可信，实测为 string。提交时顺便把这个坑同步给了它，下次大概率不会犯同样错。

说到 Fable 5，我其实没太感知到模型层面的变化。官方 changelog 说「推理能力提升 23%，代码生成准确率提升 15%」，但我日常用下来，区别更多在「它开始主动读项目上下文了」。

以前我得手动 @file 引入相关文件，现在它自己去翻 src/services/payment/ 下面所有 ts 文件，甚至能发现两年前老王写的 legacy-adapter.ts 里有个现成的字段映射工具函数，直接复用了。我当时愣住了——那个文件连我都快忘了存在。

性能上有个具体数字。我们项目 4.2 万行 TypeScript，冷启动加载上下文大概 8 秒，热加载 1.2 秒。生成那个导入功能完整流程——从读需求到跑通单测——花了 4 分 17 秒。其中 3 分钟在跑测试和修边界 case。

对比一下：上个月同事用 Cursor 做同类需求，他跟我说花了 20 分钟，主要卡在反复调整 prompt 和手动修生成的类型定义。

但我得承认，Claude Code 也有让我抓狂的时候。比如它特别爱生成「防御性代码」——每个函数开头加十几行参数校验，哪怕内部调用、类型系统已经保证了不可能为空。我得一个个删，或者在 .claude-code/config.json 里加 "defensiveCode": false，但这配置项文档里根本没写，是我翻源码发现的。

还有个细节挺有意思。它生成的注释全是英文，哪怕我明确说了「注释用中文」。后来我发现，得在系统 prompt 里加 "commentLanguage": "zh-CN"，但这配置只在 1.0.45+ 支持，更早版本无效。这种「文档滞后于功能」的情况，这半年遇到不下十次。

现在那个导入功能已经合进 develop 分支了，等周三发布。我留了个 TODO 在代码里：// TODO: 支持分块读取大文件，目前全量加载内存占用过高。测试环境跑 50MB 的 Excel，内存飙到 1.2GB，虽然没 OOM，但总觉得不对劲。

想问问各位：你们有没有遇到过 AI 生成的代码「功能对但架构不对」的情况？比如它用了递归处理树形结构，但你们项目数据量大得靠谱只能用迭代。这种时候是直接改生成的代码，还是回头调 prompt 让它重来？

我现在的经验是：改代码快，但下次它还会犯同样错；调 prompt 慢，但能治本。不过 prompt 调多了又变成另一种「配置地狱」……

先不写了，CI/CD 跑完了，我得去合个 PR。

你在实际项目中有踩过类似的坑吗？或者有更好的解决方案？欢迎在评论区分享你的经验。