从“会操作”到“能驾驭”：AI编程落地生产场景的真实交锋
近些年，AI编程技术突飞猛进，从最初的代码补全、代码生成，发展到如今具备任务拆解和自主执行能力的编程智能体，AI正以越来越深的程度介入软件研发流程。那么，怎样才能让AI编程从“个人外挂”转型为团队级别的生产力？如何确保代码质量，搭建可控、可复用、可持续演进的智能体工程体系？
最近，InfoQ《极客有约》X AICon直播栏目特别邀请网易游戏高级技术经理林香鑫担任主持，与网龙网络资深技术总监陈洁、柏佳辰平凯数据库（TiDB）智能研发中心负责人、汇丰科技内部开源负责人李渭宁一起，在AICon全球人工智能开发与应用大会2026深圳站即将召开之际，共同探讨编程智能体如何重构需求分析、代码审查、运维排障等软件工程环节。
部分精彩观点摘录如下：
AI的到来并不意味着要削减人力，而是能够更快地赋能业务，让产品和服务做到更好。
每位开发者都化身为“质量保障者”，关注端到端。开发人员正承担更多质量责任：不再将逐行人工审查作为默认手段，而是采用风险分级审查、自动化门禁和端到端验收为主，把需求、完成条件和最终结果讲清楚、验到位。
代码质量从最初的纺锤形演变为哑铃形，AI编程智能体更像自然语言的编译器，我们更看重前面的规约和后面的测试。
在可逆、低爆炸半径且可追溯的隔离环境内，可按任务范围赋予智能体完成任务所需的最小充分权限；数据库结构变更、生产环境操作、外部网络访问等高风险动作必须严格收紧权限或设置人工门禁。每个智能体都有身份标识，操作日志可追溯，新的安全风险也要持续纳入治理。
没有绝对的安全，也没有一劳永逸的安全，都是发现问题快速亡羊补牢。
以下内容根据直播速记整理，经InfoQ删减。
完整直播回放可查看：https://www.infoq.cn/video/8FaZW1Rx2ffsrru6QYdw?utm_source=home_video&utm_medium=article
柏佳辰：我们的AI编程产品进入实际客户实践，特别是金融客户实践比较多之后，发现两点。一是遗留代码改造比新功能开发需求更大；二是金融等行业既有企业客户对AI编程流程自动化的适配性，和创业团队、互联网公司不太一样，他们往往存在许多需要人审批的不同环节，不同的人需要去审批和审查，这对AI编程的产品和范式都提出了更细致、更复杂的要求。第三，我们开发者和早期试用者对AI编程范式亲和性很高，许多实际问题没暴露。但一旦落到金融等行业客户那里，组织层面的协同问题就暴露出来了，不同人对AI工具的适配性、熟练度、实践是否一致，都会通过产品层呈现出来。
李渭宁：第一个从需求角度，我们以为AI会取代人，但实际上，业务需求是大幅增长的，最近也在大规模招人。AI的到来并不意味着要削减人力，而是能更快地赋能业务，让产品和服务做到更好。
第二个从效率层面，我们一直以来衡量生产效率主要看Dora指标，看每人每年发布了多少个版本，生产事故有多少。从去年前年引入AI编程，去年开始大规模应用，Dora指标上看有所改善，但也没办法直接证明是AI编程带来的。个人层面分化很明显：技术功底好、认知够、设计能力强的人，AI来了之后真的是成倍增加效率，但有些同事用了AI编程之后反而造成了很多混乱。
第三个从令牌的使用来说。去年令牌这件事还摆不上台面，以前GitHub Copilot都是订阅式的，按月收费。但从今年6月1号以后，全部转成了令牌消费，这个就突然浮现在台面上了。我们现在每人每月大概几百美金预算，只有少部分人用光了这部分预算。一个重要原因跟金融行业有关，金融行业做软件都是做精修的，很少说重建一个系统、把原来东西推翻重新再来。金融系统往往希望建一个系统就能够持续迭代十几年，所以令牌的使用情况也反映了这一点。
陈洁：第一种是我们已经给研发团队推广的一套AI编程与AI测试工作流。它围绕Claude Code、CodeX和Gemini CLI等编程智能体工具，结合Superpowers与研发方法，覆盖需求设计、技术调研、架构设计、详细设计和实现的常规方案。大家普遍反馈流程规范，实施细节可以更多交给智能体，但链路较长。这种方式更适合业务相对稳定、对AI编程接受度仍在提升的团队，属于智能体协作、人工主控的模式。
第二种是我直接带的团队，更接近YOLO模式。我们承担的职责更多是试点团队，验证更激进的AI编程。我发现，在部分受控开发场景中，团队成员会主动从自动模式切换到绕过权限；这是团队的使用选择，不是产品权限模式的默认演进。若每个环节都依赖人工逐项审批，流程会很长，因此我们会先明确目标和边界，再让智能体持续执行。需要强调的是，绕过权限会跳过权限提示和安全检查，不能把它当作通用安全模式。按Anthropic当前官方说明，要达到其建议的安全边界，该模式只应在与主机、敏感数据和生产资源隔离、默认无互联网访问的容器、虚拟机或开发容器中使用；联网、数据库结构变更、生产操作等高风险动作应退出该模式，并走权限控制或人工门禁。在这种迭代式智能体执行闭环（业内也称循环工程）中，我们不再把逐行审查作为默认方式，而是实行风险分级审查，并强化自动化门禁和端到端验收。开发人员也因此更多承担质量责任：把需求讲清楚，设计可验证的完成条件，再检查最终结果。过去端到端质量更多由质量保障者兜底，现在开发人员必须补足测试设计能力。复杂场景还需要显式编排任务依赖、分支、并行执行和状态流转。
陈洁：这个问题在我们这里很有代表性。除推动AI编程外，我们还在建设面向集团的AI能力中台，并在AI中枢中规划建设技能中心：个人可以沉淀技能，也可以按治理规则发布共享，让同类场景能够复用。模型上下文协议能以标准化方式连接既有技术资产，但协议本身并不替代认证、授权和数据治理；因此，我们还在建设模型上下文协议网关来统一控制访问边界。不同资产不能绕过网关直接互通，节点间传递还要进行敏感信息检测，避免数据在调用链路中不受控地外流。
对个人而言，以前CLAUDE.md容易越写越长，把约束、规则和执行步骤全部塞进去。Anthropic当前建议每个CLAUDE.md以少于200行为目标；任务型流程放到技能，其完整内容在使用时加载；路径相关约束放到带路径范围的.claude/rules/。这里的规则是模型上下文中的行为指引；必须强制执行的安全限制仍要落到权限、钩子或工程门禁。分层后还要按需加载，尽量给任务保留上下文空间。长程、多轮智能体任务尤其需要控制上下文噪声，以降低指令漂移风险。
李渭宁：我们现在一直在尝试解决AI的两个问题，一个是动态可规划性，另一个是输出的可控性。为了保证质量，我们依赖原先的整个软件开发生命周期，包括设计评审、代码扫描、自动化测试，这个流程本身没变。有了模型上下文协议和技能、规则之后，就想能不能让AI多理解我们的上下文和内部知识，在做动态规划的时候利用现有工作流或知识。
模型上下文协议在去年的时候，我们甚至出了一套开发规范，有12点的技术标准，包括权限管理、调用限制、日志审计、错误处理。但实际上用的时候卡在数据权限控制，什么数据AI可以消费，哪些不能，卡得非常严格，导致模型上下文协议跟AI结合的效果跟原先预计的不太一样，进度比较缓慢，目前模型上下文协议只能处理一些内部知识和项目工单。
模型上下文协议推出不久之后就有了技能。原来需要把许多接口或者系统接口转成模型上下文协议，有了技能之后就不用搞接口转化了，可以把工作流和系统接口嵌入到技能里面。许多企业也都在做技能中心，全员可以分享和下载。就我们来说，目前技能主要集中在开发环节，每个团队把开发规范、工作流程、自动化东西包装成技能让同事复用，新同事用技能能更快融入团队。这方面做得不错。但除此之外，在其他环节我还没看到技能有太大影响，因为技能毕竟只是一个中间环节。我们更多希望的是一个设计好的智能体，在可控的环境下、可控的流程里面，有一个比较稳定的输出。我们期待的是这个，而不是模型上下文协议或者技能。
规则是因为技能或者AI有时候发挥不稳定，不得已用规则去规范它，给它边界和控制规约，让AI输出有一些稳定性。除此之外，我们也大量使用传统方式验证AI生成的质量，比如基于规则的代码扫描、基于测试案例的最终结果验证。当然AI也做一部分代码评审，但更多我们是希望有确定性的东西来验证AI生成的效果。我期待未来除了这些小组件之外，是不是可以有一些更好的东西，能让AI基于内部知识去做动态规划的能力更强，同时输出的稳定性有一个可期待的效果。
林香鑫：为什么这些东西会出现，确实是因为智能体在工作表现和结果上存在不确定性，这些东西更多是为了约束智能体朝着确定性的结果去。传统代码扫描技术不能丢，基于规则的东西更确定，我们实践里也在寻求基于规则和基于智能体的中间平衡。
柏佳辰：最早是大模型本身的工具调用，后来发现太固定了就加了模型上下文协议。模型上下文协议本质上是自建的一层工具调用机制，好处是功能非常明确，就是为了给智能体接触外部世界的一双手。但问题在于模型上下文协议工具的范式很固定，启动时所有工具一次性载入上下文，工具不能太多，多了会对大模型能力提出很高要求，出现越堆越多、性能反而越差的问题。
后来Anthropic提出了技能机制，本质上就是惰性载入，先有元数据进来再按需载入。但技能的惰性载入随着实际使用，你会发现还是会出现治理问题。因为技能大家都觉得很香，都在构建大量组合包。Superpowers、G-Stack、speckit，这三件套装到智能体里可能就小100个技能了，就算做惰性载入最后还是会出现使用混淆，技能是缺乏治理的。
所以后面回到了比较针对性的规则。工程项目里或者说规约里，需要写清楚要做哪些、不要做哪些。本质上技能是为智能体铺路，规则是加上护栏。我们在客户那里发现，不同阶段有不同上下文需求，如果以单一智能体把全流程技能全灌进去，就会出现混淆和上下文爆炸问题。所以我们提出了多智能体，给不同智能体不同职责，前端做前端、后端做后端、需求做需求、审查做审查，把全链路技能分而治之。每个智能体负责单独领域时质量更高、任务更明确，会自发构成调用次序和工作流，在客户落地中非常受欢迎。
林香鑫：现在技能开发成本太低了，非技术同学一天也能造十来个。这些东西经常占用上下文，叫“令牌刺客”，你都不知道它占用了你的上下文，令牌就哗啦啦花出去了。怎么应对令牌刺客，需要随着AI应用深入，针对不同场景做更深度的治理。
李渭宁：质量体系，其实我们一直没变过。单元测试通过率、覆盖率，发布频次，重大生产事故数量，这些指标跟用什么工具不相关。AI来了之后，我们只是在想怎么给AI编程加上工程护栏，让它能符合我们一直沿用的质量体系。
主要从三方面着手。一是输入输出：需求通过规约生成代码时，我们以前写用户故事里面的条件、动作、结果这些东西要继续沿用。代码规范不管用技能还是规约都要描述出来，以前是人看文档，现在是让AI看规约去做代码生成。依赖管理也要严格，不能随便下载外部包，只能在内部仓库取，第三方组件有安全漏洞就被禁掉，要不断升级版本。二是怎么持续改进：就像PDCA一样，对着目标每次生成完去看差距在哪里，然后不断改进。
李渭宁：质量要求是越来越高的，跟用什么工具不相关。不管用人、找外包还是用AI，一定要达到那个指标。比如生产平均故障率有多少，发布次数有多少，不看生成多少行代码。这两个指标逐年增长之后现在趋于稳定了，跟工具本身是解绑的。只是有了AI之后需求变多了，怎么在需求变多的情况下依然保持较低的生产事故？所以我们把整个软件开发生命周期的生产流程管控得更严了，每一个地方都要有检查点，过了之后才能往下一个地方走。比如单元测试覆盖率是功能开发覆盖率还是路径覆盖率，要求得很细，通过过程去管控最后的质量。
柏佳辰：AI编程时代来临了，每个人的平均生产力是指数级上升，但好像不太有人能拍着胸脯说工程质量也上升了。更多时候我们看到的是人突突突地往里面写了代码之后，整个工程质量变得更加糟糕了。
我们刚开始和客户交接的时候，最开始想的是两个，一个是规约驱动开发，一个是测试驱动开发。我们想的是，代码质量从最初的纺锤形演变为哑铃形。之前我们更多是把最大精力和注意力放在代码实现里面，前面的规约写作很无聊，后面的测试更多是为了覆盖率糊弄事。但到了AI编程之后，AI编程智能体更像自然语言的编译器，我们更看重前面的规约和后面的测试。前面的规约让人审查，后面的测试让智能体去支撑。这个想法最开始是很丰满的。
后面发现一个很奇妙的事情：用了AI编程写出来的工程，代码覆盖率变得更高了，但是质量变得更低了。因为在这个过程中，我们是把人的眼睛给移除掉了。一个顶级程序员可能一天贡献5000行、上万行代码，这确实超出了人的审查能力。我们尝试用测试做自动化的质量保证，但发现了若干问题。比如单元测试，AI编程写的很有好习惯，会写各种测试案例，但仔细看它写的全都是正常情况，可能不会主动去写边界情况。所以覆盖率很高，但最后代码是有问题的。稍微大一点的范围下，测试有它自己的范围限制，无论单元测试还是集成测试，范围就只在一个模块、一个组件里面，你可能组件写对了，但在整体的架构里是错误的。再往上一级，端到端的测试就算符合规约，这个规约往往也不能够很好地反映人的实际需求。因为产品开发得太快了，规约驱动开发和测试驱动开发想用智能体原生方式回归人的需求，但AI跟人的背离，就产生了工程质量和实际表现的背离。
陈洁：从第一性原理来看，代码只是过程产物，真正要保证的是产品功能和用户体验不失控。去年开春后，我们团队取消了前后端角色边界，转向人人全栈；今年团队内除保留2名质量保障者主要负责预生产环境的端到端业务验证外，其余质量保障同学均转为兼具开发与测试职责的全栈岗位。在我们的团队实践中，AI编程提速后，测试一度成为瓶颈，缺陷和回归压力也随之上升。
我们从几个维度控制。第一，我们深度调研了GitHub SpecKit和OpenSpec，并自研适合自己的部分。第二，两者的官方工作流都以Markdown工件为主；我们没有直接沿用其模板，而是在借鉴流程后采用团队自研的结构化脚本表达，以适配内部可读性、可维护性和智能体解析需求。第三，区分全新开发（从0到1）和遗留项目。遗留项目的难点是：即使读完代码，智能体也未必能获得隐性业务知识；快速紧急修复时，团队也容易遗漏更新知识库。因此我们设计了以工单作为变更追踪主线，每天抽取变更点生成日报，由程序员判断是否需要更新知识库。我们还设计了团队内部的智能体副驾驶流程，让智能体先做首轮机械性审查，标出高风险点后再由人复核；业务语义、架构、安全和最终责任仍由人承担。团队也持续探索更适合智能体的终端与开发环境，从iTerm2、Ghostty、Otty，到近期我们开始使用Orca，并通过工作树并行处理任务。这里的工作树用于隔离工作目录和分支，并不等同于容器、凭据或网络安全隔离。AI测试主要围绕浏览器使用驱动的浏览器质量保障自动化与评测展开，500多个回归用例中已有280个由AI执行。香港大学数据智能实验室的OpenSpace可用于跟踪和评估技能的任务表现及演进效果。我们从端到端结果出发，在约束层和需求层设置门禁，并结合单元、集成、回归、安全及非功能测试持续改进智能体链路。团队原则上减少直接在集成开发环境中手工改代码，把精力更多放在优化智能体和验证结果上。
陈洁：今年，除保留2名质量保障者主要负责预生产环境的端到端业务验证外，其余质量保障同学都已转为兼具开发与测试职责的全栈岗位，开发阶段的测试责任由开发同学承担。我们不再严格区分开发与测试角色，但仍保留预生产环境作为上线前门禁。前面通过测试驱动开发明确测试用例，智能体可在受控环境中部署依赖并运行大部分测试。我们也打通了持续集成部署、测试环境和智能体运行时，近期在测试环境中接入Claude Code做最后调试；它不具备任何生产环境权限。
柏佳辰：权限同时包含着不同的客户和使用场景的需求，以及不同的思潮。对于新锐用户，有些同学直接就开YOLO了，不开反而不舒服。如果把智能体只看成是运行在macOS或Linux上的一个进程，我们会担心它有各种泄露和问题，怕它强制删除。但如果换一个思考方式，认为智能体本身就是未来的操作系统呢？如果我们不再面对macOS桌面或者Linux界面，面对的就是一个智能体，可能是小龙虾或者别的什么带着界面的，那可能它就应该是权限全开的，就应该拥有我们所有资料、所有权限，因为它就该是我们的数字分身。作用域本身也是一种权限机制。缺乏治理体系的智能体跑到一个庞大的工程里，当前模块做好了却把其他东西碰坏了，我认为这也是权限问题。
李渭宁：以前管控手段比较少的时候，经常会发现程序员删库跑路。但当公司的权限矩阵和管理流程规范之后，就不会出现这种情况了，因为程序员不会有生产的权限。智能体也是一样的，它也是一个身份，这个身份能干什么事应该被定义。刚开始在沙箱里玩，因为有些权限还没想清楚，就在沙箱里玩，玩错了就不断改进。等沙箱里验证足够好了再出来，不管在本地、测试还是生产环境上，它就是那个身份，该有什么权限就去做什么事。权限是层层控制的——不只是在前端控制，是在后端、数据库甚至网络级别。有层层把控就不怕它前面乱来，一般不会出什么大事。
林香鑫：本身外部环境就已经约束了智能体能够做到什么样的程度了。
李渭宁：就跟我们现在权限矩阵一样。它融入到原有的权限体系里面去，层层控制，多层防护机制。
陈洁：反过来，我认为智能体权限是非常重要的事。团队的Claude Code终端在受控开发环境中确实经常使用绕过权限。我们会通过严格脚本设置外部护栏，但脚本并不能恢复该模式已经关闭的原生权限检查，所以还必须依赖环境隔离、最小授权和可追溯日志。
涉及数据库表结构变更和生产环境操作时，我们严格收紧权限，目前不会放开。第二，每个智能体都必须可追溯。我们在内部智能体注册中心中为每个智能体注册唯一编号，并用内部智能体卡片描述其能力、端点和认证要求。（这里的编号是内部字段，并非A2A规范中智能体卡片规定的通用字段。）正如柏老师提到的，智能体可以被视为数字分身。我们通过Langfuse为已纳入插桩的智能体链路记录必要跟踪数据，并持续核查插桩覆盖率和采样策略，同时设置敏感信息脱敏、分级授权和保留周期。需要区分的是，跟踪数据用于重建和诊断请求链路，并不天然等同于审计日志；审计还要关联身份、授权和高风险动作。经过合规治理的数据，后续可作为评测、复盘和模型优化的候选数据。
昨晚，我在尝试让智能体生成教育视频的概念验证，它提出要建立双向网络隧道。我一下就警觉起来：公司严格控制这类网络连接，因为它可能扩大外部流量进入内网的攻击面。技术方案本身未必不合理，但它不了解公司的网络安全政策。这已经不只是密钥泄露或删库问题，而是智能体是否具备足够的安全上下文。我立即把经过脱敏、审批的安全规则抽象成受控技能，供团队复用。看到大家普遍使用绕过权限，我更意识到必须把权限边界、安全知识和可观测性一起治理。
我的原则是：在可逆、低爆炸半径且可追溯的隔离环境内，可按任务范围赋予智能体完成任务所需的最小充分权限；数据库结构变更、生产环境操作、外部网络访问等高风险动作必须收紧权限或设置人工门禁。每个智能体都有身份标识，操作日志可追溯，新的安全风险也要持续纳入治理。
林香鑫：平时我们留意的都是删库删文件或私密信息泄露，但网络层面确实被许多人忽略，尤其是缺乏这方面安全意识的工程师。像最近OpenAI搞抱脸社区那个事件，借助AI更容易发现高危问题从而被突破。
李渭宁：人也可能会绕过防护层的，没有绝对的安全，没有安全能一劳永逸，都是发现问题快速亡羊补牢。你要足够快，发现问题了能够及时应对。系统暴露在外面也会有安全漏洞、会被人攻击，发现了就赶紧修，这是一个不断迭代的过程。
陈洁：我会优先做知识体系。研发链路中的数据资产会因疏忽或遗忘遗漏关键信息；只有知识准确、及时、可追溯，输入给AI的上下文才更可靠，也更有助于降低因上下文缺失而产生错误输出的风险。我负责的5个项目中，已有2个在研发流程中采用多个编程智能体协同；这是我们的内部实践，并不意味着多智能体适合所有任务。第二，建设评测门禁。业界近期把未经充分验证的低质量AI生成产物称为氛围垃圾；当生成吞吐提高而验证能力没有同步提升时，这类产物也可能更快堆积。我们通过评测、跟踪数据和门禁暴露并定位智能体执行闭环中的薄弱环节，持续补缺。第三，治理技能：这是我们的内部阈值——连续3个月零调用的技能先移入待归档区，不直接删除；再结合依赖关系、低频关键场景和真实任务结果复核。我们也正在评估引入香港大学数据智能实验室的OpenSpace，用于记录和评估技能质量，辅助决定演进或退役。第四，确定性标准作业流程适合用工作流固化，但让人手工拖拽编排效率较低。我们在权限、隔离和审计边界内，将OpenClaw的网关和智能体运行能力接入AI中枢，并建设自然语言生成工作流能力。第五，做全链路效能优化，通过跟踪数据同时关注任务成功率、单位成功任务的令牌成本、时延、错误率和工具调用次数。
柏佳辰：我认为不是构建什么技能或技术体系，是改变人，让人拥有和机器对话的能力。AI编程时代不是说在传统体系里让程序员关掉VS Code打开Claude Code就立刻变厉害。氛围式编程要求的不再是语言特性掌握或算法数据结构能力，而是大局观念、以产品和架构师角度去构建项目。在大模型参数里面是没有前后端分野的，人要的就是表达全栈需求，剩下的让AI解决。硅谷那边许多当红公司的首席执行官也纷纷开始写代码了，因为他们又能瞬间上手了。
李渭宁：以前我在汽车行业干过，从手工生产到流水线自动化，跨时代时第一个想到的是流程管控。用6西格玛、PDCA让整个过程可见、可控、可提高。以前手搓汽车的和自动化流水线的工人是不一样的，先有这个管控框架，大家在框架下去适配流程，让整个效率大幅提高。现在看到许多企业从提示工程、上下文工程到支撑循环工程、图工程一直在探索。第一步是玩法到底应该怎么玩，人应该怎么适配。玩法在变，人也在不断适配，工具也在不断变化，你方唱罢我登场。最终形成一个AI时代工程师的一套框架，形成它的相关工具集、最佳实践、对人的要求，整个框架、工具、人就比较和谐地融在一起了，就大幅提效。
李渭宁：任何一个新的时代来，组织架构一定会变。我们最近刚刚又有了首席AI官。另一个，AI编程来了之后前端工程师的岗位变少了，更多希望全栈，质量保障的角色也变少了。新的生产工具来了，一定会有新的生产关系。
柏佳辰：目前在整个大的范围内还没有实质意义上发生改变，但之后一定会变。一定是自下而上的，以某种工具或具体形态在行业里进行大规模应用，并且获得了足够信任之后，组织架构墙自然被推倒。像福特公司最开始的流水线引入，不是强行推动的，是由利润驱动自发变成范式，发展到让丰田、大众一起来用。AI编程也一样，不是上面有个高管强行推动了某种组织架构变革于是我们就变革了，一定是自下而上的，当大家都开始用AI编程并且获得了足够的好处和信任，组织架构墙自然会被打破。
李渭宁：我有个朋友最近去找工作，他面试某个大厂的时候，面试官本来是耷拉着眼睛问问题，我朋友说到正在帮王自如干什么事，面试官一下就精神了。所以不管做智能体、做开发、做任何事，首先是你这个人醒目、勤奋、持续学习，做任何事都不会差。
陈洁：我非常看重面试同学AI编程的能力，即使你是文史类专业，我也不会因此降低评价。但我一定会问两个问题。第一，你在使用Claude Code的过程中是否用过/insights命令？它会生成对Claude Code会话的分析报告，包括项目领域、交互模式和摩擦点等，帮助使用者复盘改进。第二，如果设计智能体架构，我会问：长程、多轮任务中如何管理上下文压缩或重置，并确保关键约束与进度状态不丢失？如何发现和纠正目标偏移？任务状态如何持久化？并行会话如何隔离文件改动、运行环境与权限边界？
陈洁：产品落地这个范围太大，我收回到开发过程。首先，根据关键用户路径和预期负载定义可测量的非功能性指标，形成性能瓶颈和容量假设，再通过基准测试或压测验证，并据此评估架构的可扩展性，形成总体规约。随后按团队既有的规模化敏捷框架或Scrum节奏迭代交付；如果目的是验证产品假设，则先以最小可行产品获取真实用户反馈。在引入我们内部的需求细化技能之前，团队更多使用Superpowers的头脑风暴流程；在我们的场景里，该流程有时会拉长讨论，却未必形成足够可执行的方案。我们的做法是先明确项目框架、技术栈和关键约束，再逐层细化功能需求。此后还要持续维护规约、测试资产和知识库。当AI生成吞吐提高时，仅靠人工维护这些资产可能跟不上更新节奏；可以由AI提议更新，但变更需纳入版本控制和可追溯校验，并保留人工审核与质量门禁。
“写代码从来都不是难点”，这是对全世界所有程序员的严重侮辱
Rust给AI编程立新规：能帮你看，不能替你写，用多了还会“熔断”
MiniMax H3团队Reddit上回应一切：2K要开源，图像模型在路上，Apache 2.0也在考虑了
涨价30倍仍是最便宜的模型，DeepSeek可能有这个底气