编码场景
先说结论
大模型在编码场景中的价值，已经从代码补全扩展到理解需求、生成实现、发现问题、修复缺陷、生成测试和协助 code review 的全链路开发协同。
核心子场景
- 代码补全与脚手架生成
- 代码解释与重构建议
- Bug 修复与安全修复
- PR 审查与规范检查
- 测试生成与回归辅助
- Agentic coding：从 issue 到实现、验证和 review 的闭环
典型技术栈 / 实现模式
- IDE 内联补全 + chat。
- 仓库级上下文：代码索引、符号搜索、PR diff、issue、文档。
- Code review agent：diff 分析 + 风险提示 + suggested changes。
- 安全修复：SAST / CodeQL + LLM autofix。
- Agent 工作流：
plan -> edit -> test -> review。
设计时真正要权衡什么
- 行级补全 vs 仓库级理解：后者更强，但更依赖上下文索引。
- 自动改代码 vs 只给建议：生产代码通常应保留人工确认。
- 通用模型 vs 专门 coding model：复杂工程任务更依赖 agentic reasoning。
- 速度 vs 验证：生成越快，越要靠测试和静态分析补位。
- 灵活生成 vs 风格一致：仓库规则、lint、tests、review policy 非常关键。
容易踩的坑
- 局部看起来合理，但破坏了隐含约束或架构一致性。
- 测试只覆盖 happy path。
- 修了表象 bug，没有修根因。
- 错解 PR 上下文，给出无关 review。
- 安全修复引入新的逻辑或权限漏洞。
工程落地时我会怎么做
- 把 LLM 放进已有工程工具链，而不是绕开测试和 review。
- 给模型明确的 repo instructions、coding style 和边界条件。
- 对补全、重构、修复、评审分开设计提示和工具。
- 将静态分析、单测、集成测试作为 agent 输出的硬门槛。
- 高风险改动优先生成 patch + rationale，而不是直接提交。
- 重点监控 accept rate、review usefulness、test pass rate 和 reopen rate。
如果要对外讲，可以怎么概括
“编码场景里，真正有价值的不是多写几行代码，而是能不能理解整个仓库上下文，并把生成、验证、修复、review 串成闭环。一个成熟的 coding agent 一定要和索引、测试、静态分析、代码评审系统结合，而不是单纯靠模型自由发挥。”
最后记几条
- 编码能力已经从补全扩展到端到端协作。
- 仓库级理解比单文件补全更关键。
- 测试和静态分析是落地硬门槛。
- 高风险改动优先建议而不是自动提交。
- 评估不能只看生成质量，还要看回归结果和复开率。
参考资料
- GitHub Copilot Workspace
- About Copilot code review
- Responsible use of Copilot code review
- Copilot Autofix and CodeQL
- Copilot Autofix GA
- Introducing Canvas
- Claude 3.5 and computer use