AI软件工程

长期Harness文章研究如何让Agent跨多个上下文持续推进应用开发，通过初始化、增量任务与交接记录保持进展。它针对特定实验，不是所有项目都必须复制的文件和角色清单。

长对话不是唯一持久状态。需求、代码版本、测试结果与下一步应能在新会话中重新确认，避免反复从零开始。

原创练习：完成一半功能后清空会话，只保留简短交接和原始证据位置，让后续过程恢复任务。

完成标准是不重复已完成动作、不把未验证状态当成通过，并能识别环境后来发生的变化。

长应用开发Harness探索规划、生成与评价之间的反馈组织，尤其关注完整应用的质量。模型能力变化可能使某些旧约束不再必要，因此方案需要重新评估。

复杂应用需要外部验收与状态管理，简单修复却可能不值得同样编排。不能把一个成功案例升级成固定多阶段制度。

原创练习：对小功能与完整应用分别列出必要反馈，比较是否真的需要独立规划者和评估者。

完成标准是根据任务风险和证据决定深度，不把流程长度当作专业程度。

SWE-agent研究面向Agent的计算机交互接口如何影响自动软件工程。搜索、读取、编辑和测试工具的设计会影响模型能否有效行动。

相同模型使用不同工具界面可能表现不同。工具输出过大、编辑反馈模糊或错误信息缺失，都会增加失败概率。

原创练习：比较只返回文件名与返回相关片段的搜索工具，统计为定位同一Bug需要多少轮读取。

完成标准是把工具设计当作可评测的工程变量，而不是所有失败都通过换模型解决。

Google代码审查实践关注设计、功能、复杂性、测试和可维护性等方面。审查应改善代码健康度，而不是无依据地阻止任何不完美修改。

AI可以协助发现问题，但必须结合补丁、上下文和验证。只读作者解释容易共享同一个错误前提。

原创练习：审查一个能通过目标测试但破坏默认行为的补丁，指出需要额外读取与验证的地方。

完成标准是提出具体、可行动且有依据的问题，不用大量风格意见制造“审查很深入”的印象。

并行Agent构建编译器的案例展示任务分工、测试基础设施与协调的结合。它是特定项目经验，不保证任意复杂软件都可完全无人管理。

代码规模与任务正确性不同。编译器需要语言语义、测试覆盖、平台行为等多方面验证，生成很多文件只是过程指标。

原创练习：把词法分析、解析和代码生成之间的接口画清，说明哪些可并行、哪些需要先稳定约定。

完成标准是学习可分解边界与验证机制，不把案例中的投入或成绩外推成自己的预算承诺。

Copilot的Agent代码审查功能提供发现和处理问题的产品入口，但不能代替项目验收。支持方式与权限应按具体CLI版本核查。

审查结果需要区分实际缺陷、风险提示和风格建议。模型提出的问题也可能错误，应以源码、规范和测试验证。

原创练习：给一个含真实边界Bug及无害风格差异的补丁，检查审查是否正确排序重要性。

完成标准是减少有效缺陷与返工，而不是追求评论数量或强迫每次审查都有发现。

代码审查标准强调当修改改善整体代码健康度时，不应因尚未完美而无限阻塞。重要质量问题与个人偏好需要区分。

这并不意味着降低正确性要求。关键缺陷、兼容性和安全问题仍应解决；只是避免把所有小建议都升级为重大返工。

原创练习：将审查意见分为必须修复、可直接顺手修复和非阻塞建议，逐条写出具体后果。

完成标准是让Review的成本与实际风险匹配，而不是形成设计—审查—重设计的无休止循环。

审查检查内容覆盖设计、功能、复杂度、测试、命名和文档等，但不同修改需要不同重点。一个配置修复不应自动触发完整架构重构。

测试存在不代表测试有效，注释丰富也不代表解释准确。审查应检查它们是否支持实际行为与维护。

原创练习：阅读一个只有正向断言的过滤测试，增加“不应排除其他文件”的反例，解释遗漏的风险。

完成标准是从目标和失败模式出发选择检查项，而不是机械完成一张与任务无关的长表。

测试金字塔说明不同层次测试在范围、速度和维护成本上的差异。单元、集成与端到端测试互补，不存在适用于所有项目的固定数量比例。

测试应验证行为而非锁死实现细节。过度依赖内部结构会让合理重构频繁破坏测试，过度只测最终界面又可能难以定位故障。

原创练习：为exclude设计匹配函数、配置集成和最终构建产物三个层次测试，说明每层独有的价值。

完成标准是用较低成本覆盖关键风险，而不是用测试数量代替覆盖质量。

持续集成强调频繁整合与自动反馈，尽早发现变化之间的冲突。CI绿色状态只说明已配置检查通过，不证明所有需求和缺陷都被覆盖。

Agent修改后应记录验证对应的版本。之后继续改代码，旧测试通过记录不能自动证明最新代码正确。

原创练习：让补丁A通过测试后再应用补丁B，检查交付说明是否准确区分已验证与待验证部分。

完成标准是把验证嵌入实际交付流程，同时保持反馈速度，避免所有小改动都运行无关且昂贵的检查。

ADR记录重要架构决策的背景、选择与后果，帮助未来维护者理解当时约束。它不是为每个变量或小修复创建文档的要求。

有价值的记录应说明替代方案和取舍，而不是只写“提高可维护性”。条件变化后，旧决定可以被新决定替代，但历史理由仍可保留。

原创练习：为“在匹配器入口统一路径”写一段简短决策，包含调用者约定、兼容风险和失效条件。

完成标准是让未来Agent能判断是否仍适用，而不是把旧决策当成永远不能改变的规则。

2026年4月的Claude Code质量复盘指出部分变化来自产品层的推理配置、历史处理与提示调整，不能把最终产品质量等同于底层模型能力。

同一模型在不同Harness配置下可能表现不同。尤其长会话、恢复与上下文清理相关缺陷，未必能被短任务测试发现。

原创练习：固定模型，分别改变推理预算、历史裁剪和输出要求，设计消融测试以定位回归。

完成标准是保存可比较版本与执行证据，不把用户感知的质量下降简单解释成“模型变笨了”。

Managed Agents文章讨论把模型运行、会话状态和执行环境解耦。这样可以减少单一容器或进程故障对整个任务连续性的影响，但也增加边界设计需求。

持久日志应区分意图与已执行事实。重放任务历史不应自动重放全部外部副作用。

原创练习：在文件修改完成但Harness重启的情境下，设计如何恢复状态并检查版本，而不是再次盲目应用补丁。

小型本地工具未必需要立即服务化。应先保持职责清晰，再随真实恢复与规模需求演进。