问题描述
有没有那种「AI 一出手，工作量瞬间减半」的体验？
请简单交代场景（任务类型、所用工具/模型、个人或团队）、前后耗时对比与可量化结果（如行数、Bug 数、上线时间），有踩坑也欢迎一并分享。
转载一下安利我 codex 朋友的文章（我学 Rust 的时候就是他和 GPT 手把手教的）
llm powered developing
来源：llm powered developing | Notion
作者：Asuka Minato
这篇文章无 ai 成分，均为真人编写。
大模型改变了我的开发习惯。
当去修一个 issue， 或者完成一个需求的时候，一般都是更改已有的代码库。
需要了解代码库的结构，要修改的位置，如何更改。最后加一个测试作为 regression test。
有一个典故叫做，改这一行只需要 1 分钟。但是知道在哪里改，为什么要这么改，就不止这 1 分钟。
而在这步，llm code agent 会花非常多的上下文进行 plan（数据来源：交了 20+ 个 pr 观察出来的结论）
人在工作的时候有两个东西很重要，context （上下文）。attention （注意力）。
上下文决定了你在工作时能够记得多少背景知识，有多少进入了你的活跃记忆。注意力则是能保证你能够专心看着在改的那一块。
大模型的上下文比人要大，特别是对于比较新的代码库，能在较短的时间内，把大量代码塞入自己的上下文，然后用工具（rg，ast-grep）找哪里需要更改，然后改。所以大模型在这方面的速度比人快。
人写代码的时候，一般都会用一个编辑器去写。编辑器提供了高亮以及错误诊断，主机提供了编译环境。确保代码能够运行以及通过测试。
而大模型，由于缺乏交互。所以在它们看来，更改的只是一个个 token 而已。
所以很多 agent 在更改完代码后，都会尝试跑一遍比如 cargo test 用输出来判断更改是否合适。
所以比较高效的方法是，把一个已有的对话内容，或者一个完整的设计文档，用大模型易读的媒介, 比如说 txt, 发给 llm, 全程以这个文档为中心进行开发。
同时自己事先配置好环境，因为大模型在配置环境方面非常难受。这里 idx.dev 是好榜样。
大模型在更改需要各种花样的地方非常好用，但是在某些更适用于机械匹配替换的地方反而没有传统工具好用。你让它写一段程序数字符串，比让它直接数要放心得多。
如果觉得大模型一直用旧的 api 请考虑使用比如 context7 让大模型能够获得最新的信息
gpt5 会用 inspect 获得 Python 函数的签名来辅助编程。
然后举几个现实的例子。改进 dify 的 codebase。
我想要类型检查覆盖尽量多的地方。就用 basedpyright 跑一遍，有100多个报错。
prompt：修复由这个指令引发的报错。之后大模型会跑这个指令，获得报错，然后去更改代码，然后继续跑指令，报错，更改代码。这个过程由于 codex 有沙箱, 全程不需要我盯着看。结束之后观察一下更改. 如果满意，并且没有类型报错我就把它合并了。
任务具有以下特征：
判定标准明确：没有类型报错。
人脑验证简洁：前后逻辑一致，类型通过。
llm 还有一个用处是 review PR
review PR 是需要脑力的，而且会打断目前的上下文。让 llm 先过一遍可以找出很多 PR 里的疏忽。比如批量重构时漏了某个地方。比如 typo，忘记删的 print。当然 llm 也会犯错，但是修正 llm 的错误相比挑 llm 的刺，心智负担低很多。
另一个意想不到的场景是翻译。注意这里不是英译中。而是根据 specification 进行代码实现。
背景：在给一个 type checker 做贡献。但是里面有些检查没有做。我就把对应检查的 specification 和 issue，以及进行检查的位置发给 llm，就自动翻代码库进行针对上下文的翻译了。效果奇佳。
在看 llm 写的代码时，还是需要自己理解给 llm 的 task 是什么，以及大致的进行思路。也就是自己需要有相关背景。
同时需要一门比较严格的语言，降低自动化纠错的精力。（现在很火的 lean4 写起来比 rust 还难受，但已经有很多用 llm + lean4 自动化的研究 + 成果了）
发给一位 llm coding 前辈, 他的补充评论
还有先给 LLM 一个可以用于评估的目标，再让它自己完成任务，这时候 TDD 会很有用，你可以 review 完测试用例就放心让它工作数小时去完成一个较大的功能，事后对结构不满意要求它重构时也不用花太多精力重复 review。