AI Coding 对软件工程的影响是什么？

AI Coding 改变的是软件交付中各环节的成本分布：代码查找、样板实现和初步测试可以更快完成，但需求澄清、系统设计、集成验证和长期维护仍然决定交付质量。程序员仍需要会读写和调试代码，因为模型产物需要被解释、修改并放进真实系统。

软件工程经验的价值，会更多体现在把目标变成明确约束、组织必要上下文、设计反馈闭环，以及判断哪些结果可以交付。AI 可以参与这些工作，但团队仍要对业务选择和系统后果负责。效果应看从需求到验收的总耗时、返工与缺陷，而不是只看生成代码速度或比例。

传统开发中，许多时间用于查接口、搬样板和实现局部逻辑。编码 Agent 可以读取文件、修改代码、执行工具并根据结果迭代，缩短这些重复操作。问题是，任务若只写“做好登录”，模型无法凭空知道会话过期、角色权限和现有客户端兼容要求。

因此需要把输入条件、行为、异常和验收讲清。对简单局部需求，几条明确条件已经足够；跨模块改动再补设计和依赖分析，流程成本应与风险相称。

模型生成的函数看起来正确，仍可能用错已有公共组件、漏掉调用方、改变错误码，或修改本不该变的文件。审查要看差异与运行路径，测试要覆盖业务条件，真实页面和状态检查补足单元测试看不到的部分。

让 AI 写测试能减少脚本工作，但若它对需求的理解有误，代码和测试可能一起错。稳定规则用编译器、静态分析和执行器检查，关键业务预期另由明确规格、样例或业务判断支撑。

生成更多代码容易，控制重复实现、抽象层级和依赖增长更难。优先复用现有组件和约定，把经过验证的构建、检查方法提供给 Agent；遇到失败时改善具体工具反馈和材料组织，而不是无限增长一份总规则。

团队也需要管理任务拆分和并发修改，避免多个 Agent 修改相同文件造成冲突。是否并行取决于任务依赖，不是 Agent 数量越多越快。

不能仅由“能生成代码”推出某类岗位必然消失。岗位还包括理解业务、处理异常、沟通和维护。更可观察的变化是：重复编码工作被压缩，能独立验收和定位问题的能力变得更重要。具体影响仍取决于组织、业务复杂度与工具可靠性。

选相近类型、复杂度的任务，记录需求澄清、实现、审查、返工到验收的全过程，并跟踪缺陷和维护负担。把工具费用和人工检查也计入；公开编码基准只能说明特定任务与环境中的表现，不能直接当成公司的生产效率预测。

国内：Snailclimb：Harness 是什么？Harness Engineering 六层架构与 Agent 工程实践：借鉴上下文、工具、验证和约束共同影响结果的分析，解释工程经验为何仍有价值。
国内：adongwanai：Coding Agent：仓库级任务、工具与验证：采用从局部补全到仓库级交付的任务差异，解释变更验证和维护成本。
国内：WeThinkIn：Agent Harness Engineering 高频考点：采用质量、成本、人工接管和回归分开衡量的方式，组织团队收益指标。
国内：datawhalechina：Agent 应用开发实践踩坑与经验分享：借鉴不清晰工具反馈导致反复无效尝试的案例，解释反馈设计的工程价值。
国外：Anthropic：Best practices for Claude Code：参考提供项目不可见约束和可执行检查的做法，说明人如何组织任务和反馈。
国外：SWE-bench团队：SWE-bench Evaluation Guide：参考真实仓库补丁评估的环境和判定范围，限制基准分数的外推。