一、一个让人不自在的事实

2025 年 7 月，非营利研究机构 METR 发布了一项随机对照试验，结果令人意外：16 名经验丰富的开源开发者，在自己维护的大型仓库中完成真实 issue 时，使用 AI 工具反而比不用多花了 19% 的时间。

更耐人寻味的是，这些开发者在实验前预期 AI 会帮他们加快 24%，实验后仍然认为 AI 帮自己快了 20%——尽管计时器给出了相反的答案。

这项研究后来被 METR 自己标注为"已过时"。到 2026 年初，他们承认当时的模型和 agent 能力已经有了质的飞跃，但一个基本问题始终悬而未决：我们究竟应该相信自己的感受，还是相信测量结果？

这个问题对今天的每一个开发者都不是学术讨论。当你用 AI Agent 在一小时内生成了一整个页面，感觉效率爆炸，但花了一天时间修 bug、调样式、重构不可维护的代码之后——你到底是快了还是慢了？

二、2026 年：Agent 已经在改写开发流程

先摆事实。Anthropic 在 2026 年初发布的《Agentic Coding Trends Report》中给出了一个清晰的分期：

• 2023 年：AI 代码补全元年
• 2024-2025 年：AI IDE 元年（Cursor、Windsurf 等）
• 2026 年：AI 编程 Agent 工程化阶段

变化不是量的，是质的。2023 年的 AI 是你的搭档，你写代码它补全。2025 年的 AI 是你的对话对象，你描述需求它生成。2026 年的 AI 则开始以你的名义参与软件交付流程——它可以被分配到 GitHub Issue，在 CI 环境中分析仓库、修改代码、运行测试、打开 PR。GitHub 官方称之为"异步同事"（asynchronous coworker），以区别于 IDE 里的"同步搭档"（sync partner）。

这与你的工作场景是吻合的。你日常用 WorkBuddy 的 Agent 模式做实际项目开发，从诊所 SaaS 到支付插件，从健康看板到数学题生成器——Agent 已经是你工作流的一部分，不是锦上添花的玩具。

但正因如此，我们更需要回答一个问题：当 Agent 开始实质性地参与工程交付时，我们用什么来保证它做的事情是正确的、安全的、可持续的？

三、AI 生成代码的安全负债正在积累

2025 年 10 月，一项针对 GitHub 上 7703 份 AI 生成文件的大规模安全分析显示，87.9% 的文件没有可识别的 CWE 映射漏洞——换言之，表面上看大多数代码是"安全的"。

但另一面是，剩下 12.1% 的文件包含可被利用的安全脆弱性。在一个拥有数百万开源仓库的生态中，这个比例意味着数十万份含有漏洞的 AI 生成代码已经流入生产环境。

更隐蔽的问题是代码质量的下滑。

GitClear 在 2025 年的分析发现，AI 辅助的仓库中"代码流失"（code churn，指代码被反复修改）的比例显著上升。开发者用 AI 快速生成大量代码，但这些代码往往需要后续反复修改才能达到可维护的标准。

你可以从自己的经验中验证这一点。你在开发诊所管理小程序时，通过 image-to-code 生成首页 UI 后，发现需要统一图标背景、替换真实 PNG 图标、去掉假数据——这些"收尾工作"不是 AI 能替你完成的，它们恰恰是让产品从"能看"变成"能用"的关键差异。

AI 擅长生成，但不擅长收尾。

这不是简单的"模型不够强"的问题。任何有工程经验的人都知道，软件工程的大部分成本不在第一版实现，而在后续维护、调试、迁移、协作。AI 在"写出来"这一步上已经很强，但在"为什么这么写""以后怎么改""有没有更好的替代方案"这些维度上，基本还是白纸。

四、MCP 与 Agent 治理：新的基础设施，新的风险

2026 年最有意思的趋势之一，是 MCP（Model Context Protocol）的普及。

MCP 的初衷很清晰——让 AI 模型能够统一地连接外部工具和系统。它在架构上正在成为 Agent 与真实系统之间的标准接口层。Anthropic 的报告中提到，MCP 已经拥有了大量社区服务器和多语言 SDK。

但这带来了一个经典的工程悖论：能力越强，风险半径越大。

OWASP 在 2026 年初发布的 MCP Top 10 安全风险清单中，列出了包括 Token 暴露、权限蔓延（privilege creep）、工具投毒（tool poisoning）、命令注入、审计缺失在内的关键威胁。每一个都不是理论风险——当你的 Agent 可以读文件、执行命令、调用 API、操作数据库时，一个被 prompt injection 影响的 Agent 可以做的事情远超一个粗心的开发者。

这对你正在开发的项目有直接意义。你最近在推进的 tt-unionpay 插件涉及支付 SDK 集成，你正在排查硬编码密钥和签名计算逻辑的安全风险——这就是 Agent 治理的微观体现：当 AI 帮你写代码时，谁在检查它写的安全代码是否正确？谁在确保密钥不会被写入仓库？

一个好的 Agent 平台应该在权限、沙箱、审计、策略下发这些方面提供基础设施，而不是让每个开发者自己去操心。但这在 2026 年仍是一个在建工程，不是成熟产品。

五、"一人公司"叙事需要降温

2025 年底到 2026 年，"一人公司"（OPC, One Person Company）成为 AI 编程领域的热门话题。叙事很动人：一个人 + AI Agent = 一个公司，一个人搞定前后端、设计、运营、客服、财务。

这个叙事的问题不在于它完全不可能，而在于它严重低估了软件生命周期中的非编码成本。

你在实际项目中遇到的每一个问题都可以用来反驳这个叙事：

• JPG 设计稿还原时，合层图片无法抠图，AI 能帮你生成代码，但设计拆分和素材提取你得自己来。
• uniApp 直播推流插件遇到死循环，AI 能生成初始代码，但排查循环原因需要理解整个插件的事件流转。
• AllinPay 支付 SDK 集成，AI 能写出接口调用，但参数补全（validtime、trxreserve、innerappid、extendparams、schemeurl）需要你逐项核对支付文档。
• 诊所小程序的首页 UI 生成后，统一图标背景、替换真实图标、移除假数据——没有一件是 AI 能替你搞定的。

我不是在否定 AI 编程的价值。相反，我认为它在很多场景下已经实实在在地提升了效率。但把"效率提升"偷换成"人可以退出了"，是一种危险的过度简化。

METR 的研究者们在 2026 年初也遇到了这个问题：他们发现开发者越来越不愿意参加"不能使用 AI"的实验组，30% 到 50% 的开发者会选择性提交他们认为 AI 最适合完成的任务。这种选择性偏差让研究者无法再通过传统的随机对照实验来测量 AI 的真实生产力影响——实验本身被 AI 的普及改变了。

这个现象的生活版本就是：你已经无法想象回到没有 Agent 的编码方式了。但它不意味着 Agent 已经完美，只不过意味着你的工作方式已经被不可逆地改变了。

六、我们应该做什么？

与其争论"AI 到底有没有用"这种没有结论的问题，不如把注意力放在更务实的方向。

1. 从"prompt 技巧"到"上下文工程"

2026 年最值得关注的转变之一，是顶级团队正在把一次性 prompt 沉淀为可复用的工程上下文。AGENTS.md、CLAUDE.md、rules、memories、skills、hooks 这些机制本质上都是在做同一件事：把你和 AI 之间的默契写下来，让下一次合作不再从零开始。

你已经在做这件事了——你使用记忆文件管理项目上下文，通过技能（skills）复现已验证的工作流程。这比大多数开发者走得远。

2. 建立 Agent 生成代码的质量门禁

AI 写的代码应该像新人提交的 PR 一样被审查。看 diff、跑测试、检查边界、关注安全和可维护性——这些不能省略。

特别是涉及支付、权限、数据安全的关键路径，代码审查不应被任何"效率"叙事绕过。你排查 AllinPay 密钥硬编码问题时的谨慎态度，就是正确的姿势。

3. 接受工具的局限性，而不是假装它不存在

一个负责任的判断：到 2026 年中，AI coding Agent 在原型开发、样板代码、测试生成、简单 bug 修复、批量重构等场景中已经非常可靠。但在跨服务架构设计、长期可维护性判断、安全审计、复杂中断调试等需要深度工程经验的场景中，它仍然是一个需要被监督的初级同事。

这不是一个暂时的状态——软件工程的核心复杂度（essential complexity）不会因为 AI 的进步而消失。Fred Brooks 在 1987 年写下的那句判断，在 AI 时代依然成立：

"没有银弹。"

七、结语

回到 METR 那项研究。它最让我在意的不是"AI 让开发者慢了 19%"（后来被更新数据温和地修正了），而是开发者主观感知与客观测量之间的巨大差距。

这个差距才是 2026 年 AI 编程面临的核心问题：我们的兴奋感是真实的，但我们对效率的感知是不可靠的。

Agent 确实在改变我们写代码的方式，但它没有改变软件工程的基本矛盾——从模糊需求到可靠交付之间的距离，不是由代码生成速度决定的，而是由理解、设计、验证和维护构成的。

工具可以变得越来越好，但把这个距离缩短到零，从来就不是工具能做的的事。