非工程师参与工程流程之后，真正稀缺的是护栏

AI Coding Agent 让一个新的现象变得普遍：非工程师开始参与工程流程。

PM 可以让 Agent 做一个功能原型，设计师可以把 Figma 想法变成可点击 demo，市场同学可以改网站文案，销售同学可以为客户做更复杂的演示。这当然是好事，因为它降低了软件表达的门槛，让更多人可以把想法变成可运行的东西。

但访谈里的提醒也很关键：当大家都在庆祝“人人都能做软件”时，很容易忘记软件仍然需要工程流程。

非工程师生成代码的问题不在于“他们不该参与”，而在于产物经常处在一个模糊地带：它到底是原型、demo、实验分支，还是准备进入生产的代码？如果边界不清，原型会混进主干，销售 demo 会暗示一个不存在的产品能力，市场页面会绕过正常 review，工程师则被迫处理更多更大、更难判断意图的 PR。

这时真正稀缺的不是代码生成能力，而是护栏。

第一类护栏是环境隔离。非工程师可以大胆生成原型，但默认应该进入 sandbox、demo repo、preview branch，而不是生产代码路径。

第二类护栏是意图说明。提交代码之前，应该先讲清楚要验证什么假设、希望改变什么体验、哪些部分只是临时实现。很多时候，工程团队需要的不是直接合并的代码，而是更清楚的需求表达。

第三类护栏是 owner 机制。任何进入生产系统的变更，都必须有工程 owner 负责架构一致性、安全、性能和可维护性。Agent 可以帮助非工程师表达想法，但不能替代生产责任。

第四类护栏是分级流程。文案、样式、demo、配置、小工具、核心业务逻辑、安全敏感代码，应该有不同的 review 强度。不能因为 AI 让代码生成变快，就把所有变更都当成同一种 PR。

这件事的积极面是：软件开发正在从工程部门的封闭活动，变成组织协作中的共同语言。坏消息是：共同语言不等于共同权限。越多人能生成代码，越需要清晰的入口、边界和验收规则。

所以，AI 时代的工程流程不是要阻止非工程师参与，而是要让参与方式可控：把想法释放出来，把风险拦在生产系统之外。

相关：Prompt Request 比 Pull Request 更适合 AI 协作、AI 时代我如何理解软件交付流程、如何防止 Agent 伪造开发证据