负责任 Agentic Coding 宣言
英文标题：A Manifesto for Responsible Agentic Coding
这份宣言主张在盲目追逐大科技公司制造的 AI 热潮与完全抵制生成式 AI 之间，采取兼顾效率、软件质量与工程师专业能力的中间路线。其核心要求是：所有生产代码都必须由人类阅读、理解并能够维护，LLM 应作为工具而非依赖或替代责任主体。文章建议缩短 AI 辅助开发的迭代周期、保持代码简单、维持人工代码评审，并对 AI 使用、数据处理和团队规范保持透明。对于开发者和行业而言，这意味着需要建立明确的 AI 政策、限制敏感数据访问，并避免将用户支持或影响人生的重要决策完全交给自动化系统。
4.8 KB
44.1 KB
33.3 KB
87.8 KB
122.6 KB
中文
在盲目屈从于大型科技公司制造的热潮，与彻底抵制生成式 AI 之间，存在一条中间道路：开发者可以善用这些新工具，同时不牺牲软件质量，也不放弃自身技艺。
基础原则 #
我们相信，数代软件工程师确立的原则与基础不仅依然适用，而且在代码生成变得廉价的时代，它们实际上比以往任何时候都更加重要。
用户和客户理应有信心相信：他们使用的软件已经由能够知情地承担责任的人类审阅并理解。这是任何可持续产品的关键要素——人类真正为工作承担责任；而纯粹的氛围编程（vibe-coding）根本无法做到这一点。
劳动者理应能够编写令自己感到自豪的代码和产品；理应能够维护易于理解和维护的代码库，而不是凌乱的意大利面条式代码。
对于 LLM 在创建过程中被使用到何种程度，保持透明非常重要——产出中究竟投入了多少人力？
代码越少通常越好——因为每一行代码都是一项负债，未来都需要维护；而任何产品的真正价值，在于与用户需求匹配的功能，以及团队对于代码库形成的共享心智模型，后者能够支持敏捷且可持续的开发。
与其尽可能快地完成功能，我们应专注于质量、向用户交付价值，以及降低风险——尤其是在处理 LLM 所特有的非确定性输出时。
LLM 是一种工具，应当被如此对待——不要让它们变成依赖、强制要求或干扰。
必须尽量减少 LLM 对环境、社区和个人造成的负面影响。
生产代码的质量 #
**每一行生产代码都必须经过人类阅读和理解。**即使 Claude 宕机，工程师也必须能够解释代码、调试代码并修改代码。
生成式 AI 可以作为工具，用于快速原型、概念验证、内部工具，或在无需对下周可能就会废弃的实现投入太多精力的情况下验证想法；它或许还可以用于为生产代码补充测试——但生产代码本身必须被人类彻底理解，这一点至关重要。
“我拿到这段廉价且快速生成的代码后，努力理解它，并将其塑造成接近我自己会写出的样子”，与“电脑吐出了这些代码，我甚至懒得尝试理解”，两者之间存在巨大的差别。
短迭代周期 #
让 Agent 接手一个大型任务、彻夜完成它，然后把测试全绿和 CI 通过当作足以将变更部署到生产环境的理由，这种做法固然很诱人——但它直接违背了所有基础原则。
保持较短的迭代周期——频繁审查 LLM 的输出并尽早纠偏——有助于控制认知范围，降低团队的认知债务，减少返工，更有效地捕获 Bug，同时优化 token 成本。
代码评审也是如此：没有人喜欢被要求审查一个数千行的大型拉取请求（PR）。将较大的功能拆分为多个 PR，以降低认知负担，是一种良好实践。如果这对人类编写的代码有效，那么对于机器生成的代码，就更有理由实行同样的政策。
保持简单 #
生成式 AI 往往会创建冗长且过度复杂的代码，常常与代码库其余部分不一致；它还喜欢添加无人阅读的长篇注释，而这些注释极易过时，因此非但无用，反而会造成困惑。应对其输出保持批判性，并寻找简化它的方法。
LLM 是模式匹配机器，因此擅长重构和处理技术债务等任务。如果你给它们一两个好例子，并要求它们在数十个其他文件中重复完成同样的工作，它们很可能会做得不错。使用 AI 减少技术债务，而不是盲目增加它。自动化枯燥任务，享受有趣任务。
不要把 AI 当成某种无所不能、永不出错的魔法程序员（它并不是）；应将其视为它本来的样子：一台非确定性机器。与人类最接近的类比，要么是专注范围较窄、但极其擅长快速完成无聊重复任务的初级开发者；要么是一位可与你头脑风暴的高级开发者，但最终仍应基于你自己的判断和经验作出决定。
代码评审 #
代码评审的目的不仅是验证变更的正确性。它还是团队成员之间共享知识、并在架构决策上保持一致的重要工具。将代码评审委托给机器，会对项目的长期可持续性造成一种隐性成本。
Agent 可以对变更进行预审查，处理细枝末节的问题；作者应在麻烦队友进行评审之前先解决这些建议——但归根结底，让每一项代码变更都经过两双（人类）眼睛审视，仍然与过去一样有价值。
透明度 #
你的用户有权知道，他们购买的是高质量产品，还是无人愿意阅读的劣质垃圾内容。他们有权知道，他们的个人数据和商业机密是否会离开你的服务器；不能仿佛“Agentic 工作流”就能神奇地让这种行为变得可以接受。
你的员工或队友应当获得清晰说明和适当培训，了解哪些工具、行为、模式和工作流是可接受的、对他们有哪些预期；他们也应拥有拒绝过度 AI 强制要求的权利。
你应该制定 AI 政策。
敏感数据 #
绝不能授予 LLM 访问 PII（个人身份信息）、商业机密或凭证的权限。应在本地开发中使用虚拟数据。妥善隔离沙盒环境。不要让 Agent 访问生产系统。
用户支持与决策 #
支持人类的最佳方式，是让他们与人类交谈。将用户支持自动化看起来像是一项不错的降本措施，但已经多次被证明会降低客户满意度和留存率。如果用户的问题简单明了，且只需引用常见问题解答（FAQ）即可解决，大多数用户宁可自己阅读 FAQ，也不愿让机器人错误地向他们转述。如果他们决定花时间在线聊天或打电话，他们遇到的问题很可能比机器人能够处理的情况更复杂、更个人化。如果确实有必要，你可以将初步分流交给机器人——但应将这类交互保持在最低限度，明确说明回复由机器生成，而不是试图伪装成人类，并为用户提供一种便捷的方式转接人工服务。
内容审核，以及会影响人们生活的决策（例如招聘或出租公寓），都应始终由能够为决策承担责任的人类作出。如果确有必要，可以使用机器人进行初步分流，但实际决策应始终由人类完成。
审慎选择模型与使用场景 #
不同模型带来的成本各不相同——不仅包括金钱成本，也包括生态、社会乃至地缘政治成本。与其屈从于最新的热潮，不如就使用哪种模型，以及更重要的是是否要使用任何模型，作出知情决策。将 AI 视为工具——不要让它变成依赖、强制要求或干扰。
English / 原文
Somewhere between mindlessly giving in to the hype created by big tech and entirely boycotting generative AI there’s a middle ground that lets developers make good use of the new tools without sacrificing software quality or giving up on their craft.
Fundamentals #
We believe that the principles and fundamentals established by generations of software engineers are not only still relevant, but in the age of cheap code generation they are actually more important than ever.
Users and customers deserve to have confidence that the software they use has been reviewed and understood by humans who can take informed accountability for it. It’s a crucial element of any sustainable product – humans taking actual responsibility for the work, something that is simply not possible from pure vibe-coding.
Workers deserve to be allowed to create code and products that they’re proud of ; to work on codebases that are understandable and maintainable – not on sloppy spaghetti code.
It’s important to be transparent about the extent to which LLMs were used in the creation process – how much human power was involved in creating the output?
Less code is generally better – as every line of code is a liability that will have to be maintained over time – while the true value of any product lies in its functionality that matches the users’ needs and in a shared mental model of the codebase within the team that allows for agile and sustainable development.
Rather than producing features as quickly as possible we should focus on quality , delivering value to users, and on risk reduction – especially when working with non-deterministic output that characterises LLMs.
LLMs are a tool and should be treated as such – don’t turn them into a dependency, obligation or disruption.
It’s important to minimise the negative impact of LLMs on the environment, communities and individuals.
Quality of production code #
Every line of production code must have been read and understood by a human. Engineers must be able to explain the code, debug it and modify it – even when Claude is down.
Generative AI can be used as a tool for fast prototyping, proofs-of-concept, internal tools, for validating ideas without having to invest much effort into an implementation that you might throw away next week, maybe even for covering production code with tests – but the production code itself being thoroughly understood by humans is critical.
There’s a massive difference between “I took this cheaply and quickly generated code and worked on understanding it and shaping it into something close to what i would’ve written myself” and “the computer spewed it out, i didn’t even bother trying to understand it”.
Short iteration cycles #
As tempting as it is to just define a large task for an agent to finish overnight, and then consider green tests and passing CI as a good enough reason to deploy the changes to production – that goes directly against all the fundamentals.
Keeping iteration cycles short – reviewing the LLM output often and course-correcting early – helps keep the mental scope small, reduce cognitive debt of the team, reduce re-work, catch bugs more effectively, and also optimise token costs.
Same applies to code reviews: nobody likes being asked to review a massive thousands-lines pull request. It’s a good practice to split larger features into multiple PRs in order to reduce the mental overhead. If that’s what works for code written by humans, there are even more reasons to apply that same policy to code generated by machines.
Keep it simple #
Generative AI tends to create verbose and overcomplicated code, often inconsistent with the rest of the codebase; it loves to add lengthy comments that nobody reads and that are very prone to becoming outdated and therefore confusing rather than useful. Be critical of their output and look for ways to simplify it.
LLMs are pattern-matching machines – therefore excelling at tasks like refactoring and tackling technical debt. If you give them one or two good examples and ask them to repeat the work on dozens of other files, they’re likely to do a good job. Use AI to reduce technical debt – not mindlessly increase it. Automate boring tasks – enjoy the fun ones.
Instead of treating AI as some kind of magical, infallible programmer that can do anything (it can’t), treat it a non-deterministic machine that it is; the closest analogy to a human would be either a junior developer with a narrow focus, but a huge talent to complete boring, repetitive tasks very fast, or a senior developer that you can brainstorm ideas with, but ultimately make decisions based on own judgment and experience.
Code reviews #
The purpose of a code review is not just to validate the correctness of the change. It’s also a vital tool for sharing knowledge among the team members and for staying on the same page on architectural decisions. Delegating code reviews to machines comes at an invisible cost to long-term sustainability of the project.
Agents may pre-review a change to get the nitty-gritty out of the way, and the author should address those recommendations before bothering a teammate for a review – but ultimately there’s still just as much value in having two pairs of (human) eyes on every code change as ever.
Transparency #
Your users deserve to know whether they’re buying a quality product or being fed slop nobody has even bothered to read. They deserve to know whether their personal data and trade secrets are ever leaving your servers as if ‘agentic workflows’ magically made that okay.
Your workers or teammates deserve clarity and proper training on what tools, behaviours, patterns and workflows are acceptable and expected of them; they deserve the right to refuse excessive AI mandates.
You should have an AI policy.
Sensitive data #
LLMs must never be granted access to PII (personally identifiable information), trade secrets or credentials. Use dummy data for local development. Sandbox environments properly. Don’t give agents access to production systems.
User support and decision-making #
The best way to support humans is by letting them talk to humans. Automating user support might seem like a good cost-cutting measure, but has proved countless times to decrease customer satisfaction and retention. If the user’s issue was straightforward and fixable by quoting FAQs, most users would rather just read the FAQ themselves than have a bot misquote it for them. If they decided to take time to chat or to call, they likely have a problem that’s more messy and personal than a bot can handle. You might delegate the initial triaging to a bot, if you really have to – but keep that interaction minimal, make it clear that responses are machine generated rather than trying to pass it off as a human, and give the user an easy way to get connected to a human.
Moderating content and making decisions that impact people’s lives (like hiring or renting an apartment) should always be made by humans who can take responsibility for the decisions. Use a bot for initial triaging, if you really have to, but keep the actual decision-making to humans.
Mindful choice of models and use cases #
Various models have different costs – not just monetary, but also ecological, social and even geopolitical. Rather than giving in to the latest hype, make informed decisions which model to use and – more importantly – whether to use any at all. Treat AI as a tool – don’t turn it into a dependency, obligation or disruption.