[{"data":1,"prerenderedAt":337},["ShallowReactive",2],{"article-ai-can-code-but-not-build-products\u002F":3},{"id":4,"title":5,"body":6,"cover":297,"date":298,"description":299,"draft":300,"extension":301,"faq":302,"featured":300,"meta":315,"navigation":316,"path":317,"readingTime":318,"seo":319,"seoKeywords":320,"stem":328,"summary":329,"tags":330,"type":334,"updated":335,"video":335,"__hash__":336},"articles\u002Farticles\u002Fai-can-code-but-not-build-products.md","AI 能轻松解需求，却将迭代的坑留给了人",{"type":7,"value":8,"toc":279},"minimark",[9,16,19,22,25,28,35,40,47,50,53,56,72,75,81,85,88,91,94,97,103,107,110,117,124,131,134,137,141,153,156,165,174,179,183,186,191,194,197,201,204,207,211,214,217,221,224,227,230,234,237,243,246,249,252,255,258,261,265,268,273,276],[10,11,12],"blockquote",{},[13,14,15],"p",{},"AI 可以接管越来越多研发步骤，但如果流程只奖励“尽快把需求做出来”，它也会更快地把局部最优写进系统。",[13,17,18],{},"最近几个月，我在代码 Review 里反复看到一种情况。",[13,20,21],{},"我们的历史项目正在做 AI 化改造，新项目也已经大量使用 AI。随着信任增加，AI 不再只是补几行代码，而是开始直接理解需求、设计方案、开发并集成。",[13,23,24],{},"功能确实更快上线了。可当我们回头审查完整代码时，却发现不少需求是以补丁方式接进去的：AI 尽可能让当前功能跑通，却很少主动考虑产品能力是否重复、模块边界是否被破坏，以及下一次修改要付出什么代价。",[13,26,27],{},"这些局部正确的代码不断累积，最后变成技术债。继续让 AI 在上面开发，项目只会越来越臃肿。",[13,29,30,31],{},"这让我重新思考一个问题：",[32,33,34],"strong",{},"AI 会写代码，甚至能独立交付需求，是否就等于它会做产品？",[36,37,39],"h2",{"id":38},"从一个需求到一个产品中间还隔着什么","从一个需求到一个产品，中间还隔着什么？",[13,41,42],{},[43,44],"img",{"alt":45,"src":46},"从单点用户需求经过价值判断、能力整合和架构设计，演化为可持续迭代的产品","\u002Fa\u002Fai-can-code-but-not-build-products\u002Fneed-to-product.webp",[13,48,49],{},"如果只是做一次性脚本、个人工具或者概念验证，补丁未必是问题。代码完成任务后就结束使命，快速得到结果比长期维护更重要。",[13,51,52],{},"但这篇文章讨论的是另一类软件：它有真实用户，承载真实业务数据，需要长期响应需求。",[13,54,55],{},"用户提出的通常是一个具体问题，甚至已经带着他设想的解决方案。产品不能机械地把每句话变成功能，而要继续判断：",[57,58,59,63,66,69],"ul",{},[60,61,62],"li",{},"这个问题是否具有持续价值？",[60,64,65],{},"现有能力能否解决，只是用户没有找到？",[60,67,68],{},"新需求应该扩展哪个能力，还是建立新的能力？",[60,70,71],{},"它与其他用户、流程和数据是什么关系？",[13,73,74],{},"开发也不只是把方案翻译成代码。它还要保证今天的实现不会封死明天的变化，并在结构开始阻碍业务时进行调整。",[13,76,77,78],{},"所以，",[32,79,80],{},"AI 降低的是当前需求的实现成本，没有自动消除判断、整合、验证和维护成本。",[36,82,84],{"id":83},"ai-为什么容易变成需求外包","AI 为什么容易变成“需求外包”？",[13,86,87],{},"这不完全是 AI 的问题，而是我们给它的目标造成的。",[13,89,90],{},"大多数研发任务只描述“要增加什么”，验收标准也集中在“功能能否运行”。在这样的目标下，AI 选择改动最少、最容易通过当前验收的路径非常合理。",[13,92,93],{},"它看到的是一个局部任务，人却要承担整个系统的未来。",[13,95,96],{},"如果 AI 不知道产品为什么采用当前流程，不知道某个模块不能反向依赖另一个模块，也不知道一段看似多余的抽象正在保护数据边界，那么复制一套相似逻辑、增加一个条件分支或者绕过原有接口，往往是完成任务的最快办法。",[13,98,99,100],{},"“像外包”只是一个比喻。优秀的外包团队同样可以做出可维护系统，AI 也能参与架构设计和重构。真正的问题是：",[32,101,102],{},"我们是否只购买了交付结果，却没有把长期目标和质量反馈交给它。",[36,104,106],{"id":105},"真正缺的不是三个职位而是三套反馈","真正缺的不是三个职位，而是三套反馈",[13,108,109],{},"过去我们习惯说，一个完整团队需要产品、设计和开发。现在我更愿意把它们理解成三套不能缺席的反馈，而不是三个固定职位。",[13,111,112,113,116],{},"第一套是",[32,114,115],{},"用户价值反馈","。它负责判断问题是否真实，结果是否有用，而不是把用户提出的方案原样实现。",[13,118,119,120,123],{},"第二套是",[32,121,122],{},"产品一致性反馈","。它把点状需求放回完整产品，判断应该复用、扩展、合并还是拒绝，避免每个需求都长出自己的入口、概念和流程。",[13,125,126,127,130],{},"第三套是",[32,128,129],{},"工程可持续反馈","。它检查模块边界、数据所有权、兼容性、测试和回滚，控制每一次变化带来的复杂度。",[13,132,133],{},"这三种能力可以由一个人承担，也可以由多个 Agent 辅助。关键不在团队里有多少角色，而在于三种目标是否真正进入研发与验收流程。",[13,135,136],{},"同时也要警惕另一个极端。产品能力矩阵不是越完整越好，架构也不是越面向未来越好。为尚未出现的需求提前抽象，同样可能制造昂贵的复杂度。重构应该回应已经出现的结构性阻力，而不是猜测所有未来。",[36,138,140],{"id":139},"ai-加速的不只是开发也可能是复杂度","AI 加速的不只是开发，也可能是复杂度",[13,142,143,144,152],{},"软件工程对这件事早有观察。",[145,146,151],"a",{"href":147,"rel":148,"target":150},"https:\u002F\u002Fplg.uwaterloo.ca\u002F~migod\u002Fpapers\u002F2013\u002FlehmanPaper.pdf",[149],"nofollow","_blank","软件演化研究","指出，持续使用的软件必须不断适应环境；如果没有专门投入控制复杂度，其结构会在持续修改中逐渐恶化。",[13,154,155],{},"AI 没有创造这条规律，但它显著提高了变化的速度。",[13,157,158,159,164],{},"一项覆盖近 5000 名技术从业者的",[145,160,163],{"href":161,"rel":162,"target":150},"https:\u002F\u002Fdora.dev\u002Fdora-report-2025\u002F",[149],"软件研发调查","发现，AI 使用与交付吞吐量正相关，但仍与交付稳定性负相关。自动化测试、成熟的版本控制和快速反馈，决定了更快的代码产出会变成生产力，还是变成更多不稳定变更。",[13,166,167,168,173],{},"另一项分析约 30 万次 AI 提交的",[145,169,172],{"href":170,"rel":171,"target":150},"https:\u002F\u002Farxiv.org\u002Fhtml\u002F2603.28592v1",[149],"2026 年预印本研究","发现，不同工具均有超过 15% 的提交引入至少一个静态分析问题，约四分之一的问题在后续版本中仍然存在。这项研究依赖静态分析，且尚未完成正式同行评审，不能证明 AI 必然制造技术债，但它至少提醒我们：功能被合并，不代表维护成本已经消失。",[13,175,176],{},[32,177,178],{},"AI 更像一个放大器。好的产品与工程系统会被放大，只追求局部交付的流程也会被放大。",[36,180,182],{"id":181},"怎样让-ai-从需求外包变成研发系统","怎样让 AI 从“需求外包”变成研发系统？",[13,184,185],{},"我的答案不是收回 AI 的权限，而是把约束、独立审查和人的责任一起放进自动化流程。",[187,188,190],"h3",{"id":189},"先建立项目的演化说明书","先建立项目的“演化说明书”",[13,192,193],{},"在仓库中维护少量长期文档：产品原则说明目标用户和明确不做的事；能力地图记录现有能力与边界；架构文档约束模块职责、依赖方向和数据所有权；决策记录解释重要方案为何被采用或放弃。",[13,195,196],{},"AI 接需求前先读这些文档。它们不需要写成百科全书，只保留会影响未来决策的约束，并随项目变化更新。",[187,198,200],{"id":199},"复杂需求先交方案不要立刻交代码","复杂需求先交方案，不要立刻交代码",[13,202,203],{},"编码前要求 AI 回答：真实问题是什么，应该复用或扩展哪项能力，会影响哪些模块和数据，是否引入新概念，怎样迁移、测试和回滚。",[13,205,206],{},"人在这里做第一次 Review。方向错了，代码生成得越快，返工和技术债增长得越快。",[187,208,210],{"id":209},"用多-agent-形成制衡","用多 Agent 形成制衡",[13,212,213],{},"复杂需求可以让不同 Agent 分别负责需求分析、产品能力判断、架构影响、开发和测试。最后再用一个没有参与实现的 Review Agent，对照原始需求、架构约束和完整代码差异独立审查。",[13,215,216],{},"重点不是 Agent 数量，而是不要让同一个 Agent 既实现方案，又为自己的方案做最终背书。低风险修改无需启动完整流程，跨模块、改数据或影响公共接口时再升级审查。",[187,218,220],{"id":219},"建立架构师-rule-review-skill","建立“架构师 Rule + Review Skill”",[13,222,223],{},"Rule 保存长期硬约束，例如模块依赖方向、数据归属、禁止绕过的公共接口、新增能力前必须搜索已有实现，以及数据模型变更必须附带迁移和回滚方案。",[13,225,226],{},"Skill 则定义每次审查的流程：读取产品与架构文档，检查完整变更集，搜索重复能力，分析模块边界、依赖方向、新状态和新接口，最后按严重程度输出阻断问题、改进建议和待偿还技术债。",[13,228,229],{},"逐次 Commit 可以做轻量检查，但合并前必须再看完整变更集。很多架构问题并不存在于某一行代码，而是出现在多个正确修改组合之后。",[187,231,233],{"id":232},"在自动化-pipeline-中插入人工闸门","在自动化 Pipeline 中插入人工闸门",[13,235,236],{},"一套更稳妥的流程是：",[13,238,239],{},[240,241,242],"code",{},"需求分析 → 方案生成 → 人审方案 → AI 实现 → 自动测试与架构检查 → 独立 Agent Review → 高风险变更人审 → 发布",[13,244,245],{},"修改核心数据、权限、跨模块依赖、公共接口和不可逆操作时，必须由人确认。低风险、测试充分且容易回滚的变更，才适合自动集成。",[13,247,248],{},"AI 的权限不应统一放开，而应由失败成本和可验证性决定。",[187,250,251],{"id":251},"定时检查系统有没有偏航",[13,253,254],{},"局部 Review 看不到系统正在缓慢变形。可以每周或每两周让架构 Agent 检查重复能力、循环依赖、相似字段、不断扩大的条件分支、长期未删除的临时代码，以及修改频率超过测试能力的模块。",[13,256,257],{},"巡检结果必须进入技术债清单，写明风险、影响范围、处理时机和验收标准。核心模型变化、同一模块连续被修改或线上事故发生时，还应立即触发额外审查。",[13,259,260],{},"当同一规则第三次重复、一个需求必须修改多个不相关模块，或者测试准备时间已经超过功能实现时间，就该考虑重构。这样，重构回应的是已经出现的演化方向，而不是对未来的想象。",[36,262,264],{"id":263},"ai-可以接管执行但不能凭空获得所有权","AI 可以接管执行，但不能凭空获得所有权",[13,266,267],{},"过去我认为，当 AI 掌握代码能力，每个人都会拥有自己的“私人程序员”。现在我仍然相信它会让更多人创造出自己的工具，但我要给这个判断补上一个边界：",[13,269,270],{},[32,271,272],{},"造出一个能用的工具，和维护一个持续演化的产品，不是同一件事。",[13,274,275],{},"AI 可以参与需求分析、产品设计、架构决策、编码、测试和 Review，甚至承担其中大部分执行工作。但产品最终要长成什么，哪些代价可以接受，什么时候应该停下来偿还复杂度，仍然需要明确的责任主体。",[13,277,278],{},"当写代码越来越廉价，真正稀缺的就不再是实现，而是知道产品应该怎样生长，并愿意为它的长期演化负责。",{"title":280,"searchDepth":281,"depth":281,"links":282},"",3,[283,285,286,287,288,296],{"id":38,"depth":284,"text":39},2,{"id":83,"depth":284,"text":84},{"id":105,"depth":284,"text":106},{"id":139,"depth":284,"text":140},{"id":181,"depth":284,"text":182,"children":289},[290,291,292,293,294,295],{"id":189,"depth":281,"text":190},{"id":199,"depth":281,"text":200},{"id":209,"depth":281,"text":210},{"id":219,"depth":281,"text":220},{"id":232,"depth":281,"text":233},{"id":251,"depth":281,"text":251},{"id":263,"depth":284,"text":264},"\u002Fa\u002Fai-can-code-but-not-build-products\u002Fcover.webp","2026-07-23","当 AI 开始直接承接需求、写代码并完成集成，交付变快了，技术债也可能同步加速。真正可持续的 AI 研发，需要把产品约束、架构反馈和人工责任放进同一套流程。",false,"md",[303,306,309,312],{"q":304,"a":305},"为什么 AI 写出的功能能用，项目却越来越难维护？","AI 通常接收到的是局部需求和当前验收标准，最短路径是让功能尽快运行。如果缺少产品能力地图、架构边界、自动化测试和整体审查，它可能通过复制逻辑、增加分支或绕过接口完成任务，把整合与维护成本留给以后。",{"q":307,"a":308},"普通人能用 AI 独立开发长期产品吗？","可以，但不能只管理提示词和功能列表。长期产品还需要验证用户价值、保持产品能力一致、控制系统复杂度，并在数据迁移、权限和跨模块修改等关键节点承担最终责任。",{"q":310,"a":311},"怎样避免 AI 编程不断添加补丁？","先让 AI 提交变更方案，再允许编码；把产品原则、能力地图和架构规则放进仓库；由独立 Agent 审查完整变更集；用测试和架构检查建立质量门槛，并定期检查重复能力、依赖关系和高频修改区域。",{"q":313,"a":314},"AI 自动开发流程中哪些环节必须由人审查？","涉及产品方向、核心数据模型、权限、跨模块依赖、公共接口、不可逆操作和缺少可靠回滚方案的变更，都应由人审查。低风险、测试充分且容易回滚的修改才适合自动集成。",{},true,"\u002Farticles\u002Fai-can-code-but-not-build-products",9,{"title":5,"description":299},[321,322,323,324,325,326,327],"AI 开发产品","AI 编程技术债","AI 代码维护","AI 产品开发","软件架构演化","AI 独立开发","AI 代码质量","articles\u002Fai-can-code-but-not-build-products","AI 降低了需求实现的成本，却没有自动消除产品判断、系统整合、质量验证和长期维护的成本。对于有真实用户和业务数据、需要持续迭代的软件，必须用产品、架构和工程反馈约束 AI 的局部最优。",[331,332,333],"AI 应用","产品思考","独立开发","article",null,"S2q4-R4S40HJhz7bAYtlMtq4jxLRNkxaPSbnAyj6Ni4",1787031137560]