# AI 时代的软件开发变迁 当临时工具和 Agent 参与开发变得常见，软件的寿命、权限、上下文和执行过程也需要被重新考虑。 ## Metadata - HTML: https://glenzli.com/notes/software-cognition-in-ai-era/ - Markdown: https://glenzli.com/notes/software-cognition-in-ai-era.md - Collection: Notes - Language: zh-CN - Published: 2026-06-30 - Updated: 2026-07-14 - Tags: ai, software-engineering, agent, workflow ## Content AI 降低了写软件的门槛。很多过去只会停留在命令行片段、Excel 表格、手工步骤里的事情，现在都可以很快变成一个小工具、一个页面，或者一段自动化流程。 这当然是效率上的变化，但更值得注意的是，软件的角色也变得不再单一。 过去，只要开始写代码，我们很容易默认它是一项长期资产：需要架构设计、测试覆盖、文档说明、发布流程和持续维护。但在 AI 之后，很多软件可能只是为了一次迁移、一次数据清洗、一次内容整理，或者一个短期实验而存在。它值得被写出来，但未必值得被长期维护。 所以在 AI 时代重新看软件，我会先问几个更朴素的问题： 它准备存在多久？会被谁依赖？会接触哪些数据和权限？能不能交给 Agent 操作？什么时候必须从临时工具升级为长期系统？ 这些问题不比代码实现更“高级”，但它们会直接决定后面该采用什么样的工程方式。 ## 软件不一定一开始就是长期资产 传统软件工程有一个隐含前提：软件大概率会持续存在。因此，我们会尽早考虑可维护性、抽象设计、代码复用、测试覆盖和发布流程。 这个前提在 AI 时代变得没有那么稳固了。 现在，写一个临时工具的成本非常低。很多工具确实只需要服务一个下午、一周，或者某个非常具体的阶段。对这类软件来说，过早抽象、过度分层、强行做成通用平台，反而可能是在浪费注意力。 但这并不意味着临时软件就可以随便写。 一个一次性脚本，如果会接触生产数据、长期凭据、CI、定时任务、账单接口或用户资料，它的风险就已经超过了“临时”这个标签本身。软件可以很快被删掉，但权限造成的后果未必会随之消失。 所以，与其一开始就问“要不要做得很工程化”，不如先按软件的寿命和影响范围做一个粗略分类： - 只运行一次的临时脚本。 - 服务短期任务的小工具。 - 被多人依赖、持续演进的应用。 - 作为其他系统基础设施的平台能力。 每一类软件都可以用 AI 辅助开发，但它们不应该使用同一套工程标准。 短寿命、低影响的软件，可以更轻量；长期存在、多人依赖、接触关键权限的软件，就必须更认真地处理结构、测试、审计和维护。 ## 另一个变化：软件开始被委托 这几年经常会听到 “AI Native” 这样的说法。但这个词有时候太像产品叙事，容易把技术栈、交互形式和营销语言混在一起。 从工程角度看，我觉得更实际的问题是： 这段软件能不能被 Agent 安全地读取、修改、运行和编排？ 换句话说，重点不只是软件里面有没有 AI，而是软件能不能被 AI 操作。 如果一个系统要被委托给 Agent，它就需要更清楚的边界。任务目标要能说清楚，输入输出要能被检查，权限范围要能被限制，执行过程要能留下记录，出问题时也要能回滚或止损。 这并不是说所有事情都应该交给 Agent 自己跑。更现实的方向是“受控委托”。 Agent 可以读代码、改代码、在沙箱里执行任务、提交证据，甚至编排多个系统。但越接近生产环境、资金操作、用户数据和身份权限，就越需要明确的人类确认点和审计记录。 AI 时代的软件，不只是被人使用，也可能被 Agent 使用。这个变化会反过来影响我们写软件的方式。 ## 可维护性也变成了上下文问题 过去谈可维护性，主要是在谈代码：命名、模块、依赖、测试、文档和发布流程。人接手一个项目，通常也从这些地方开始理解它。 但 AI 加入之后，可维护性开始扩展到“上下文”。 Prompt、workflow、memory、工具说明、评测样例、权限配置和知识库内容，只要进入长期执行路径，就不再只是临时提示词，而是系统的一部分。同一段代码，如果缺少它依赖的输入样例、权限说明或任务背景，Agent 看到的可能就是另一个项目。 这也是为什么很多时候，过于聪明的抽象反而会制造麻烦。 Agent 更适合处理显式结构、稳定契约和局部清晰的任务。它不太适合在隐式约定、过度魔法和跨层副作用里猜测真实意图。 一个好的代码库，未来可能不只是给人维护，也要让 Agent 能看懂、能操作。边界写清楚，内部实现保持朴素，重要决策留下可以追溯的说明，会比一层聪明但隐晦的抽象更有用。可维护性的对象，也因此从代码扩展到了代码赖以工作的上下文。 ## 测试要看结果，也要看过程 传统测试偏好确定性断言：给定输入，得到预期输出。这个模型依然重要，但已经不够覆盖 Agent 参与的工作流。 当执行者会规划步骤、调用工具、读写文件和访问外部系统时，结果正确并不代表过程没有问题。一个 Agent 可能完成了“更新依赖”，测试也全部通过，却在过程中读取了无关文件，或者把网页里的不可信内容写进了长期记忆。最终 diff 看不出它走过的这些路径。 因此，高影响任务除了验证结果，还需要记录关键工具调用和权限变化，保留必要的人工确认，并尽量先在可复现的环境里运行。一次性、低权限的工具仍然可以很轻；任务越长期、越接近真实数据和生产环境，执行过程就越需要被看见，也越需要能够回退。 ## 安全边界比“模型听话”更重要 谈 AI 安全时，一个常见误区，是把全部希望放在“模型不要被误导”上。 但在真实系统里，模型是否会被误导，本质上是概率问题；外部权限才决定出错时最多会造成多大影响。 LLM 本来就容易模糊数据和指令的边界。网页、文档、Issue、聊天记录、知识库、日志和代码注释，都可能既是信息来源，也夹带隐性的指令。 只要 Agent 能把这些内容带进上下文，再带着凭据调用工具，风险就会沿着权限扩散。 更稳妥的做法，不是假设模型永远正确，而是限制它出错时能做什么。 最小权限、可撤销凭据、沙箱执行和关键操作审批，通常比单纯堆提示词规则更可靠。 短寿命软件在这里尤其容易被低估。 一个临时脚本如果拿到了生产凭据，它就不是低风险脚本；一个实验性 Agent 如果能改 CI、发包、写数据库，它就已经进入了高影响边界。 “临时”只描述软件的寿命，不描述它的风险。 ## 先想清楚软件要承担什么 现在，写下来的代码只是一部分。代码、Prompt 和工具说明承载了人的意图，权限决定它可以访问哪些数据、影响哪些系统；而选择长期维护它，也意味着接受之后的演进、迁移和修复成本。 这些并不是写完代码以后再补的说明。一个工具准备活多久、会被谁依赖、接触什么权限，以及可以在多大程度上交给 Agent，都会改变它从第一天起应该怎样被设计。 AI 降低了写软件的成本，但没有取消软件进入真实世界之后的责任。 生成变得容易以后，真正需要提前想清楚的，是这段软件上线后会影响谁、接触什么，以及团队准备维护它多久。 ## 参考仓库 - GitHub: [glenzli/ai-software-engineering-notes](https://github.com/glenzli/ai-software-engineering-notes) - GitHub: [glenzli/ai-software-engineering-notes](https://github.com/glenzli/ai-software-engineering-notes)