面试被问"你在内部有哪些 AI coding 提效工作"——只答"用了 Copilot"是最弱的回答。真正值钱的是：具体怎么用、量化结果、以及你设计的工作流。

这篇文章把我的实战拆成可复制的全链路。

六个场景，按 ROI 排序

不是所有编码环节都值得交给 AI。按投入产出比排：

1. 代码生成 —— 模板代码 / CRUD / 配置文件，提效 3-5x
2. 单元测试生成 —— 覆盖率从 40% → 80%+，省下大量机械劳动
3. Code Review —— 自动查常见问题（安全 / 性能 / 命名），压缩人工 review 时间
4. 文档生成 —— API 文档 / CHANGELOG / README，提效 5-10x
5. 调试辅助 —— 贴报错自动给修复建议
6. Onboarding —— 新人用 AI 快速理解陌生代码库

注意排序：文档和单测的 ROI 往往最高，因为它们最机械、最不依赖创造性，却最容易被人类拖延。

三层落地：个人 / 团队 / CI

提效不是装个插件就结束，要分层次铺开：

• 个人层：Cursor / Claude Code 日常编码，把重复活交给模型
• 团队层：内部 AI coding 工具 + 共享 prompt 库，把个人经验变成团队资产
• CI/CD 层：自动测试生成、自动 code review，每次 PR 触发

关键认知：不要让 AI 只在你本地跑。把它沉到 CI，才能从"个人快一点"变成"团队不出低级错"。

你有没有过这种经历：让 Agent 帮你写一段小脚本，生成的内容看起来语法完美，一跑就炸？报错信息通常是一串让你怀疑人生的 &、$、反引号乱码，然后你盯着那几行代码看了十分钟——最后发现，模型把 bash 的反斜杠转义 \" 写在了 PowerShell 命令里。

这个问题我称之为 Shell 转义歧义，在 LLM + 终端自动化这个交叉点上表现得尤其明显。本质是：LLM 生成的是一个扁平字符串，而 shell 执行的是多层嵌套的语义解析，任何一层出了偏差，最终执行的命令就和你预期完全不一样。

一、双重解析：模型以为的 vs shell 实际执行的

LLM 采用自回归方式逐 token 生成，它"以为"自己写的是结构化的命令。但实际上，如果这个字符串被 shell=True（Python subprocess）或者 Invoke-Expression（PowerShell）执行，就等于经历了 两次独立的解析：

• 第一层：LLM 生成字符串时的"心智解析"——它以为引号配对是对的
• 第二层：shell 自己再做一次 tokenize / word-splitting

这两层之间没有任何契约式的保证。模型输出一个字符串，shell 拿过去按自己的规则重新分词，然后交给操作系统执行。任何一层的歧义，都会导致最终行为和预期背离。

而且这种错误往往是 延迟发现的：代码写入时没报错，运行时才炸。模型只能"事后诸葛亮"式地不断打补丁修改脚本，一个命令可能要循环三四次才终于跑通。

二、为什么 PowerShell 比 bash 更容易踩坑

Shell 本来就不简单，但 PowerShell 在这个问题上尤其难搞。有几层原因：

1. 转义符混淆 PowerShell 的转义符是反引号 `，不是 \。但模型的训练数据里 bash 语法占绝对多数，它经常无意识地混用 bash 习惯——比如用 \" 来表示引号转义，这在 PowerShell 里会被原样当作普通反斜杠处理，导致完全不同的解析结果。

2. 语义差异大 PowerShell 对 $、@()、&、| 有一套完全不同于 bash 的语义：变量插值、数组字面量、调用操作符、管道。模型很容易犯"语法迁移错误"，把 bash 的逻辑套用到 PowerShell 上。