# AI 时代的软件开发变迁 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-08-17 - Tags: ai, software-engineering, agent, workflow ## Content AI 降低了写软件的门槛。 许多过去只会停留在命令行片段、Excel 表格和手工步骤里的事情，现在可以很快变成小工具、页面或自动化流程。 变化不只发生在效率上。 软件的角色也没那么单一了。 过去，只要开始写代码，我们很容易默认它会成为长期资产：需要架构、测试、文档、发布和持续维护。但在 AI 之后，许多软件只为一次迁移、一次数据清洗、一次内容整理或一个短期实验存在。 它值得被写出来，却未必值得被长期维护。 所以，现在看一段软件，我更想先问：它准备活多久？会被谁依赖？接触什么数据和权限？能否交给 Agent 操作？什么时候必须从临时工具升级为长期系统？ 这些问题不比代码实现更高级，却会直接决定代码应该怎样写。 ## 软件未必是资产 传统软件工程有一个隐含前提：软件大概率会持续存在。 所以，我们尽早考虑可维护性、抽象、复用、测试和发布流程。只要时间足够长，这些投入就有机会被摊销。 这个前提正在松动。 写一个临时工具已经很便宜。许多工具确实只需要服务一个下午、一周，或者某个非常具体的阶段。对它们来说，过早抽象、过度分层、强行做成通用平台，反而是在浪费注意力。 但临时软件也不能随便写。 一个只运行一次的脚本，如果接触生产数据、长期凭据、CI、定时任务、账单接口或用户资料，风险就已经超过“临时”这个标签。 软件可以很快被删掉，权限造成的后果不会跟着消失。 所以，工程方式不该只看代码量。更重要的是寿命和影响：一次性、低权限、结果可验证的工具可以很轻；长期存在、多人依赖、接触关键权限的软件，必须认真处理结构、测试、审计和维护。 临时只描述寿命，不描述风险。 ## 软件开始被委托 这几年经常听到 “AI Native”。这个词很容易把技术栈、交互方式和产品叙事搅在一起。 从工程角度，更实际的问题是： > 这段软件能否被 Agent 安全地读取、修改、运行和编排？ 重点不只是软件里面有没有 AI，也是软件能不能被 AI 操作。 如果一个系统要交给 Agent，它就需要更清楚的边界。任务目标要能说清，输入输出要能检查，权限范围要能限制，执行过程要留下记录，出了问题也要能回滚或止损。 这不意味着所有事情都该让 Agent 自己跑。更现实的是受控委托。 Agent 可以读代码、改代码、在沙箱里执行任务、提交证据，也可以编排多个系统。但越接近生产环境、资金、用户数据和身份权限，就越需要明确确认点和审计记录。 软件不再只被人使用，也会被 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)