原文内容

AI 辅助写代码的经历

背景

我平时会把 AI 当作一个长期在线的结对编程伙伴，而不是简单的代码生成器。它最适合帮我处理那些上下文多、步骤杂、但目标比较清楚的任务：读已有代码、补小工具、解释报错、写测试、整理文档，以及把临时想法快速变成可以运行的原型。

为了避免把个人项目细节暴露出来，这里只记录一些通用的使用方式和经验。

常见使用场景

1. 快速理解陌生代码

接触一个新仓库时，我通常先让 AI 帮我梳理目录结构、入口文件、核心模块之间的关系。相比自己一点点跳转文件，AI 可以更快给出一张粗略地图：哪些文件负责配置，哪些文件负责业务逻辑，哪些地方可能是测试或构建入口。

不过这一步我不会完全相信总结，而是会让 AI 给出对应的文件位置和判断依据。这样后续排查问题时，我能把它的结论和真实代码对上。

2. 从需求草稿生成可运行原型

很多小工具一开始只有一个模糊目标，例如“把一批文本整理成统一格式”或“从日志里统计关键字段”。我会先用自然语言描述输入、输出和边界条件，让 AI 生成第一版脚本，然后自己补充真实样例并运行验证。

这种方式最大的价值不是省掉所有编码时间，而是把“空白文件”阶段缩短了。先得到一个能跑的版本，再围绕具体错误逐步修改，效率会高很多。

3. 调试报错和定位问题

遇到编译错误、测试失败或运行时异常时，我会把错误信息、相关代码片段和已经尝试过的排查步骤一起交给 AI。它通常能帮我把可能原因按优先级排出来，例如依赖版本不一致、路径配置错误、边界条件遗漏、异步流程没有等待完成等。

我比较常用的方式是让 AI 先解释错误栈，再给出最小修改建议。这样可以避免一上来做大范围改动，也更容易判断修复是否真的针对根因。

4. 补测试和文档

AI 很适合处理重复但需要耐心的工作，例如根据函数行为补参数化测试、为命令行工具整理使用示例、把零散记录改成 README。它也能提醒一些容易漏掉的边界情况，比如空输入、非法参数、重复数据、路径不存在等。

对测试代码我会格外仔细地审查，因为 AI 有时会写出“看起来覆盖了场景，但断言并没有真正验证行为”的测试。我的习惯是先跑测试，再手动制造一两个失败场景，确认测试确实能抓住问题。

我总结的协作方式

1. 先说明约束，再让 AI 写代码。 包括语言版本、依赖限制、输入输出格式、不能修改的文件、期望的错误处理方式等。
2. 把任务拆小。 让 AI 一次只完成一个明确步骤，比一次性生成很大的模块更可靠。
3. 要求给出修改依据。 重要改动需要能对应到具体错误、具体需求或具体文件，而不是只看起来合理。
4. 始终自己运行和审查。 AI 可以加速搜索、生成和重构，但最后的正确性仍然要靠测试、阅读和实际运行确认。
5. 保留迭代记录。 当一个问题排查了多轮，我会让 AI 总结已尝试方案和当前结论，避免在同一个方向反复试错。

收获

AI 辅助编程对我的最大帮助，是把很多低层次的摩擦降了下来：查 API、写样板代码、补格式、解释错误、整理文档都更快了。这样我可以把更多精力放在需求是否合理、接口是否清晰、测试是否覆盖关键行为这些更重要的问题上。

同时，它也让我更重视工程习惯。因为 AI 生成代码很快，如果没有清晰的约束、版本控制和验证流程，很容易把问题扩大。真正有效的使用方式并不是“让 AI 全自动完成”，而是把它放进一个可检查、可回滚、可测试的开发流程里。

总体来说，AI 已经成为我日常写代码时很稳定的辅助工具。它不替代判断，但能显著提高从想法到可运行结果的速度。