1. 从46万行代码说起一个产品人的反思起点先交代背景。过去一年多我把AI深度嵌入了日常开发流程累计生成了大约46万行代码。这个数字听起来唬人但拆开看并不神秘——它包括了业务逻辑、测试用例、配置文件、数据清洗脚本、接口胶水层、文档注释甚至一些一次性验证用的原型代码。如果按传统手写的方式这些工作量大概需要一个三到五人的小团队干上大半年。但真正让我停下来写这篇东西的不是“AI能写多少代码”这件事本身而是当代码量堆到这个量级之后我发现自己对“做产品”的理解被彻底搅动了一遍。以前我信奉的那套逻辑——先把需求想清楚再拆功能再排优先级再写代码——在AI参与之后很多环节的权重变了。有些环节变得极其廉价有些环节反而变得前所未有的昂贵。这篇文章适合谁看如果你是一个独立开发者、小团队的产品负责人、或者正在犹豫要不要把AI引入自己工作流的技术人那接下来的内容应该能帮你少走一些弯路。我不打算讲什么“AI改变世界”的大道理只聊我在实际操作中踩过的坑、总结出的方法以及那些让我半夜睡不着觉的重新思考。核心关键词就几个AI辅助开发、产品思维、代码生成、需求验证、技术债。这些词在后面的章节里会反复出现因为它们构成了我这一年多实践的主线。2. 当代码生成变得廉价什么反而变贵了2.1 代码产能过剩带来的第一个反直觉现象刚开始用AI写代码的时候我的第一反应是兴奋。一个接口从设计到实现以前可能要磨半天现在几分钟就能跑通。一个数据处理的脚本描述清楚输入输出AI直接给你一个能用的版本。那种感觉就像突然获得了一台挖掘机以前用铲子挖土的日子一去不复返。但很快我就发现了一个问题代码写得越快我越不知道自己在做什么产品了。以前写代码慢这个“慢”本身是一种保护机制。因为实现成本高所以你会反复问自己这个功能真的有必要吗有没有更简单的做法用户真的需要这个吗这种摩擦虽然让人烦躁但它强迫你把注意力放在真正重要的事情上。当实现成本趋近于零的时候这种保护机制就消失了。你会不自觉地陷入一种“既然这么容易那就都做了吧”的状态。于是功能越加越多代码越堆越厚但产品的核心价值反而越来越模糊。我印象特别深的一次是给一个内部工具加功能。原本只是想加一个数据导出结果因为AI写代码太快我顺手把筛选、排序、分组、自定义字段、导出格式选择全做了。最后这个功能上线用户只用了一次还是用的默认导出。那多出来的几千行代码全成了维护负担。这里的关键教训是代码生成成本降低之后决策成本反而成了瓶颈。你需要把省下来的时间重新投入到“判断什么该做、什么不该做”上面。2.2 技术债的形态变了但本质没变传统意义上的技术债通常是因为赶工期、妥协方案、缺乏设计导致的。代码写得烂结构混乱后面的人接手想死。但在AI辅助开发的环境下技术债呈现出一种新的形态看起来每一段代码都挺规范但整体架构是散的。为什么会这样因为AI擅长的是局部生成。你给它一个函数签名它能写出漂亮的实现你给它一个模块描述它能搭出合理的结构。但它不负责全局一致性。当你一段一段地让AI生成代码最后拼在一起的时候会发现命名风格不统一、错误处理策略不一致、数据流向混乱、抽象层次参差不齐。我试过让AI帮我重构一个模块结果它把原本耦合但清晰的结构改成了看起来解耦但实际上更复杂的形态。因为AI的“重构”是基于它见过的模式而不是基于你这个项目的实际演进历史。所以我现在养成了一个习惯AI生成的代码必须经过一次人工的“架构对齐”。具体做法是每积累一定量的AI生成代码就停下来做一次全局审视检查命名、错误处理、数据流、依赖关系是否还保持一致。这个工作很枯燥但省不得。2.3 从“怎么写”到“写什么”的重心转移这一年多最大的收获是让我重新理解了产品开发的重心应该放在哪里。以前我会花大量时间在“怎么写”上面用什么框架、怎么设计接口、怎么优化性能、怎么处理边界情况。这些当然重要但它们本质上是实现层面的问题。当AI能帮你解决大部分实现问题的时候你的核心竞争力就转移到了“写什么”上面。“写什么”包括用户真正的问题是什么哪些功能是必须的哪些是锦上添花的产品的核心闭环是什么哪些假设需要验证这些问题以前也会想但因为实现成本高你不得不在想清楚之前就动手然后在动手过程中调整。现在你可以更快地动手但这也意味着你更容易在没想清楚的情况下就冲出去。我的做法是把省下来的编码时间强制分配到需求验证上。具体来说每当我有一个新想法先用AI快速做一个可交互的原型然后拿给真实用户看。以前做一个原型可能要一周现在可能半天就出来了。但关键是原型出来之后不要急着加功能而是先观察用户怎么用。3. 需求验证的节奏被彻底改变了3.1 快速原型让“验证”变得廉价但“观察”变得稀缺AI辅助开发最大的价值之一就是让原型制作变得极其快速。你有一个想法描述给AI它帮你生成一个能跑的东西。这个速度带来的直接好处是你可以在一天之内验证好几个方向。但这里有个陷阱原型做得越快你越容易跳过观察环节。我以前做原型因为成本高所以会特别珍惜每一次用户测试的机会。会认真设计测试脚本会仔细观察用户的操作会反复回放录屏。现在原型来得太容易反而容易陷入“做一个、看一眼、觉得不行、再做一个”的循环。看起来效率很高但实际上没有积累任何深度认知。后来我给自己定了一个规矩每个原型至少观察三个真实用户的使用过程并且记录下他们卡住的地方、犹豫的地方、以及他们自己都没意识到的操作习惯。这个规矩强迫我慢下来但收获远比快速迭代大得多。3.2 用AI做用户访谈的辅助分析除了做原型我还把AI用在了用户访谈的分析上。以前做用户访谈录音整理、编码、归类、提炼洞察一套流程下来要好几天。现在可以把访谈录音转成文字然后让AI帮我做初步的主题聚类和情感分析。但这里有个重要的注意事项AI的分析结果只能作为参考不能替代你自己的判断。AI擅长的是模式识别它能告诉你“有5个用户提到了加载速度慢”但它不能告诉你“为什么加载速度慢这件事对用户来说这么重要”。后者需要你结合业务背景、用户场景、产品阶段来综合判断。我的做法是让AI做第一遍粗筛把明显不相关的信息过滤掉把可能的主题列出来。然后我自己再听一遍录音重点听那些AI标记为“情绪强烈”的片段。这样既节省了时间又保证了洞察的深度。3.3 一个具体的验证案例说一个具体的例子。当时我想给一个工具加一个“智能推荐”功能想法是让AI根据用户的历史操作推荐下一步动作。用AI辅助我大概花了半天时间做出了一个能用的原型。拿给用户测试的时候我发现了一个之前完全没想到的问题用户根本不看推荐。不是推荐不准而是他们压根没注意到那个推荐区域。因为他们的注意力完全集中在主操作区推荐区域在视觉上被忽略了。这个发现让我重新思考了整个功能的定位。后来我把推荐从“独立区域”改成了“嵌入到主操作流程中的提示”效果好了很多。如果按照以前的开发节奏我可能会花两周把这个功能完整做出来然后上线后发现没人用。现在半天做原型一天做测试两天就调整了方向。这里的关键经验是AI加速的是“做”的过程但“看”和“想”的过程一点都不能省。甚至因为做得快了你更需要刻意留出观察和思考的时间。4. 产品决策的权重重新分配4.1 功能优先级的判断逻辑变了以前排优先级通常会考虑“实现成本”这个维度。一个功能如果实现成本高即使价值不错也可能被排到后面。但在AI辅助开发的环境下实现成本这个维度的权重应该大幅降低。我现在排优先级主要看三个维度用户价值、验证成本、维护成本。用户价值不用多说这是根本。验证成本是指我需要花多少精力才能确认这个功能是否真的有用。维护成本是指这个功能上线之后我需要持续投入多少资源来保证它正常运行。实现成本为什么权重降低因为AI能帮你快速实现但快速实现不等于没有成本。代码写出来之后测试、调试、部署、监控、修bug这些环节的成本并没有因为AI而显著降低。所以我现在更关注的是“这个功能上线后我能不能hold住”。4.2 从“能不能做”到“该不该做”AI让“能不能做”这个问题变得不那么重要了。大部分功能只要你能描述清楚AI都能帮你做出一个版本。但“该不该做”这个问题反而变得更加关键。我见过太多团队因为AI能快速实现就疯狂加功能。结果产品变得越来越臃肿用户越来越困惑维护越来越困难。这就像给一个已经吃饱的人不停上菜看起来丰盛实际上是一种浪费。我的判断标准很简单如果这个功能不能直接帮助用户完成核心任务或者不能显著提升核心体验那就先不做。这个标准听起来很朴素但在AI能快速实现一切的环境下坚持这个标准反而需要更大的定力。4.3 一个决策框架的调整我把自己用的决策框架调整成了这样维度以前权重现在权重说明用户价值高高不变始终是核心实现成本高低AI大幅降低了实现门槛验证成本中高快速原型让验证更频繁但观察需要刻意投入维护成本中高代码量增加后维护负担显著上升战略契合中高功能越多越需要聚焦核心方向这个框架不是绝对的但对我来说它帮助我在AI辅助开发的环境下保持了对产品方向的清醒判断。5. 实操中的具体方法和避坑指南5.1 我的AI辅助开发工作流经过一年多的摸索我形成了一套相对稳定的工作流。分享出来供参考但请注意这套流程是基于我个人的项目特点和习惯你需要根据自己的情况调整。第一步需求拆解。拿到一个需求先不急着写代码而是用自然语言把需求拆成若干个可独立验证的小块。每个小块都要有明确的输入、输出和验收标准。这一步我通常自己完成因为AI容易把需求拆得太细或太粗。第二步原型生成。对于每个小块用AI生成一个最小可运行的原型。这个原型不需要考虑代码质量只要能跑通就行。目的是快速验证想法。第三步人工审查。AI生成的原型我会快速过一遍重点看逻辑是否正确、边界情况是否处理、有没有明显的安全问题。这一步不能省因为AI有时候会生成看起来合理但实际上有问题的代码。第四步重构与整合。把验证通过的原型按照项目的整体架构进行重构和整合。这一步我通常自己动手或者让AI辅助但由我把控方向。第五步测试与部署。写测试用例跑通测试部署上线。测试用例可以让AI生成初版但我会补充边界情况和异常场景。5.2 常见问题与排查技巧在实际操作中我遇到了一些高频问题整理成速查表问题现象可能原因排查方法解决思路AI生成的代码跑不通依赖缺失或版本不匹配检查import和package版本明确指定依赖版本逻辑看起来对但结果不对边界条件处理错误用极端输入测试补充边界测试用例代码风格不一致多次生成缺乏统一约束检查命名和结构制定代码规范并注入提示性能不达预期算法复杂度高或资源泄漏profiling工具分析优化关键路径集成后出现奇怪bug模块间接口不匹配检查数据流和类型统一接口定义特别提醒AI生成的代码永远不要直接上生产环境。哪怕它看起来再完美也要经过人工审查和测试。我踩过好几次坑都是因为觉得“这段代码很简单应该没问题”结果上线后出了各种意料之外的问题。5.3 几个让我印象深刻的坑坑一过度信任AI的“最佳实践”。AI会倾向于生成它见过的“标准”写法但这些写法不一定适合你的项目。比如它可能会给你生成一个复杂的抽象层而你的项目其实只需要一个简单的函数。我的应对方法是在提示里明确说明项目的规模和复杂度让AI根据实际情况调整方案。坑二忽略代码的可读性。AI生成的代码有时候会过于紧凑或者使用一些不常见的写法。这些代码机器能跑但人看起来费劲。我现在会要求AI在生成代码时加上清晰的注释并且避免过度使用语言特性。坑三测试覆盖不足。AI生成的测试用例往往只覆盖正常路径对异常路径和边界情况的覆盖不够。我现在会专门让AI生成异常场景的测试然后自己再补充一些。坑四安全漏洞。AI可能会生成存在安全风险的代码比如SQL注入、XSS、不安全的反序列化等。这个问题在Web开发中尤其突出。我的做法是所有涉及用户输入和外部数据的地方都要人工审查一遍。6. 对“做产品”这件事的重新理解6.1 产品经理和工程师的边界在模糊以前做产品产品经理负责想清楚要做什么工程师负责实现。这个分工在AI辅助开发的环境下变得越来越模糊。因为当实现变得容易的时候产品经理也可以快速做出原型来验证想法工程师也可以更深入地参与产品决策。我自己的角色就在这个模糊地带。我既要想产品方向又要动手实现还要做用户验证。这种角色融合有好处也有挑战。好处是决策链条短反馈快。挑战是容易陷入细节失去全局视角。我的应对方法是刻意切换视角。做产品决策的时候强迫自己不看代码写代码的时候强迫自己不想产品。虽然实际上很难完全分开但这种刻意的切换能帮助我保持清醒。6.2 速度与质量的平衡点在哪里AI让开发速度大幅提升但质量呢我的观察是AI能帮你快速达到“能用”的水平但从“能用”到“好用”仍然需要大量的人工投入。“能用”意味着功能跑通了没有明显bug。“好用”意味着性能达标、体验流畅、边界情况处理得当、代码可维护。这中间的差距AI能帮你缩短但不能帮你消除。我现在会把“能用”和“好用”分开对待。先用AI快速做到“能用”验证方向是否正确。如果方向对了再投入精力打磨到“好用”。如果方向错了快速放弃损失也不大。6.3 什么才是真正稀缺的能力这一年多下来我越来越觉得在AI辅助开发的环境下真正稀缺的能力是判断力。判断什么需求值得做判断什么方案更合适判断什么时候该停下来判断什么代码该重写判断什么功能该砍掉。这些判断AI能提供参考但不能替你决策。另一个稀缺的能力是品味。同样一个功能不同的人做出来体验可能天差地别。这种差异往往不在于技术实现而在于对细节的把握、对用户感受的理解、对整体一致性的追求。AI可以帮你实现但品味需要你自己培养。7. 一些具体的操作建议7.1 如何写出更好的AI提示经过大量实践我总结了几条写提示的经验明确上下文。告诉AI你的项目规模、技术栈、代码风格、目标用户。这些信息越具体生成的代码越贴合实际。分步骤描述。不要一次性让AI生成一个大模块而是拆成小步骤每一步都有明确的输入输出。这样生成的代码质量更高也更容易调试。提供示例。如果你有现有的代码风格或模式给AI一个示例让它照着写。这比用文字描述有效得多。要求解释。让AI在生成代码的同时解释它的设计思路和关键决策。这能帮你快速判断代码是否合理。迭代优化。第一版生成后根据结果调整提示再生成第二版。通常两到三轮就能得到比较满意的结果。7.2 代码审查的重点AI生成的代码审查时重点关注这几个方面逻辑正确性核心逻辑是否符合预期边界条件是否处理安全性是否有注入风险、权限问题、数据泄露风险性能是否有明显的性能瓶颈算法复杂度是否合理可维护性命名是否清晰结构是否合理注释是否充分一致性是否与项目现有代码风格一致7.3 什么时候不该用AI虽然我是AI辅助开发的积极实践者但有些场景我仍然坚持自己动手核心架构设计。架构决策需要考虑项目的长期演进、团队的技术栈、业务的特殊性这些AI很难全面把握。关键算法实现。涉及复杂业务逻辑或性能敏感的算法我会自己写或者至少自己设计好框架再让AI填充细节。安全相关代码。认证、授权、加密、输入验证这些安全关键的部分我会自己写并仔细审查。需要深度思考的决策。比如产品方向、技术选型、团队分工这些需要结合大量上下文和判断AI只能提供参考。8. 最后分享几个实用技巧第一个技巧建立自己的代码片段库。AI生成的代码如果质量不错就整理到自己的片段库里。下次遇到类似场景可以直接复用也可以作为提示的示例。这个习惯帮我节省了大量重复劳动。第二个技巧用AI做代码审查。除了让AI生成代码我还让它帮我审查代码。把一段代码贴给AI问它“这段代码有什么问题”往往能发现一些我自己忽略的细节。当然AI的审查结果需要你自己判断不能全信。第三个技巧定期做“代码考古”。每隔一段时间回顾一下之前AI生成的代码看看哪些还在用哪些已经废弃哪些需要重构。这个过程能帮你理解自己的开发模式也能发现一些潜在的问题。第四个技巧保持手写代码的习惯。虽然AI能帮你写大部分代码但完全依赖AI会让你的编码能力退化。我每周会刻意手写一些代码保持手感。这就像健身不能完全依赖器械徒手训练也很重要。第五个技巧记录决策日志。每次做重要决策的时候记录下当时的背景、考虑的因素、最终的选择和预期结果。过一段时间回头看能帮你校准自己的判断力。这个习惯在AI辅助开发的环境下尤其重要因为决策频率变高了没有记录很容易迷失。这一年多和AI一起写代码的经历让我对做产品这件事有了很多新的理解。有些理解是技术层面的有些是方法论层面的还有些是心态层面的。但最核心的一条是工具越强大使用工具的人越需要清醒。AI能帮你更快地到达某个地方但去哪里、为什么去、到了之后做什么这些问题永远需要你自己回答。
1. 从46万行代码说起一个产品人的反思起点先交代背景。过去一年多我把AI深度嵌入了日常开发流程累计生成了大约46万行代码。这个数字听起来唬人但拆开看并不神秘——它包括了业务逻辑、测试用例、配置文件、数据清洗脚本、接口胶水层、文档注释甚至一些一次性验证用的原型代码。如果按传统手写的方式这些工作量大概需要一个三到五人的小团队干上大半年。但真正让我停下来写这篇东西的不是“AI能写多少代码”这件事本身而是当代码量堆到这个量级之后我发现自己对“做产品”的理解被彻底搅动了一遍。以前我信奉的那套逻辑——先把需求想清楚再拆功能再排优先级再写代码——在AI参与之后很多环节的权重变了。有些环节变得极其廉价有些环节反而变得前所未有的昂贵。这篇文章适合谁看如果你是一个独立开发者、小团队的产品负责人、或者正在犹豫要不要把AI引入自己工作流的技术人那接下来的内容应该能帮你少走一些弯路。我不打算讲什么“AI改变世界”的大道理只聊我在实际操作中踩过的坑、总结出的方法以及那些让我半夜睡不着觉的重新思考。核心关键词就几个AI辅助开发、产品思维、代码生成、需求验证、技术债。这些词在后面的章节里会反复出现因为它们构成了我这一年多实践的主线。2. 当代码生成变得廉价什么反而变贵了2.1 代码产能过剩带来的第一个反直觉现象刚开始用AI写代码的时候我的第一反应是兴奋。一个接口从设计到实现以前可能要磨半天现在几分钟就能跑通。一个数据处理的脚本描述清楚输入输出AI直接给你一个能用的版本。那种感觉就像突然获得了一台挖掘机以前用铲子挖土的日子一去不复返。但很快我就发现了一个问题代码写得越快我越不知道自己在做什么产品了。以前写代码慢这个“慢”本身是一种保护机制。因为实现成本高所以你会反复问自己这个功能真的有必要吗有没有更简单的做法用户真的需要这个吗这种摩擦虽然让人烦躁但它强迫你把注意力放在真正重要的事情上。当实现成本趋近于零的时候这种保护机制就消失了。你会不自觉地陷入一种“既然这么容易那就都做了吧”的状态。于是功能越加越多代码越堆越厚但产品的核心价值反而越来越模糊。我印象特别深的一次是给一个内部工具加功能。原本只是想加一个数据导出结果因为AI写代码太快我顺手把筛选、排序、分组、自定义字段、导出格式选择全做了。最后这个功能上线用户只用了一次还是用的默认导出。那多出来的几千行代码全成了维护负担。这里的关键教训是代码生成成本降低之后决策成本反而成了瓶颈。你需要把省下来的时间重新投入到“判断什么该做、什么不该做”上面。2.2 技术债的形态变了但本质没变传统意义上的技术债通常是因为赶工期、妥协方案、缺乏设计导致的。代码写得烂结构混乱后面的人接手想死。但在AI辅助开发的环境下技术债呈现出一种新的形态看起来每一段代码都挺规范但整体架构是散的。为什么会这样因为AI擅长的是局部生成。你给它一个函数签名它能写出漂亮的实现你给它一个模块描述它能搭出合理的结构。但它不负责全局一致性。当你一段一段地让AI生成代码最后拼在一起的时候会发现命名风格不统一、错误处理策略不一致、数据流向混乱、抽象层次参差不齐。我试过让AI帮我重构一个模块结果它把原本耦合但清晰的结构改成了看起来解耦但实际上更复杂的形态。因为AI的“重构”是基于它见过的模式而不是基于你这个项目的实际演进历史。所以我现在养成了一个习惯AI生成的代码必须经过一次人工的“架构对齐”。具体做法是每积累一定量的AI生成代码就停下来做一次全局审视检查命名、错误处理、数据流、依赖关系是否还保持一致。这个工作很枯燥但省不得。2.3 从“怎么写”到“写什么”的重心转移这一年多最大的收获是让我重新理解了产品开发的重心应该放在哪里。以前我会花大量时间在“怎么写”上面用什么框架、怎么设计接口、怎么优化性能、怎么处理边界情况。这些当然重要但它们本质上是实现层面的问题。当AI能帮你解决大部分实现问题的时候你的核心竞争力就转移到了“写什么”上面。“写什么”包括用户真正的问题是什么哪些功能是必须的哪些是锦上添花的产品的核心闭环是什么哪些假设需要验证这些问题以前也会想但因为实现成本高你不得不在想清楚之前就动手然后在动手过程中调整。现在你可以更快地动手但这也意味着你更容易在没想清楚的情况下就冲出去。我的做法是把省下来的编码时间强制分配到需求验证上。具体来说每当我有一个新想法先用AI快速做一个可交互的原型然后拿给真实用户看。以前做一个原型可能要一周现在可能半天就出来了。但关键是原型出来之后不要急着加功能而是先观察用户怎么用。3. 需求验证的节奏被彻底改变了3.1 快速原型让“验证”变得廉价但“观察”变得稀缺AI辅助开发最大的价值之一就是让原型制作变得极其快速。你有一个想法描述给AI它帮你生成一个能跑的东西。这个速度带来的直接好处是你可以在一天之内验证好几个方向。但这里有个陷阱原型做得越快你越容易跳过观察环节。我以前做原型因为成本高所以会特别珍惜每一次用户测试的机会。会认真设计测试脚本会仔细观察用户的操作会反复回放录屏。现在原型来得太容易反而容易陷入“做一个、看一眼、觉得不行、再做一个”的循环。看起来效率很高但实际上没有积累任何深度认知。后来我给自己定了一个规矩每个原型至少观察三个真实用户的使用过程并且记录下他们卡住的地方、犹豫的地方、以及他们自己都没意识到的操作习惯。这个规矩强迫我慢下来但收获远比快速迭代大得多。3.2 用AI做用户访谈的辅助分析除了做原型我还把AI用在了用户访谈的分析上。以前做用户访谈录音整理、编码、归类、提炼洞察一套流程下来要好几天。现在可以把访谈录音转成文字然后让AI帮我做初步的主题聚类和情感分析。但这里有个重要的注意事项AI的分析结果只能作为参考不能替代你自己的判断。AI擅长的是模式识别它能告诉你“有5个用户提到了加载速度慢”但它不能告诉你“为什么加载速度慢这件事对用户来说这么重要”。后者需要你结合业务背景、用户场景、产品阶段来综合判断。我的做法是让AI做第一遍粗筛把明显不相关的信息过滤掉把可能的主题列出来。然后我自己再听一遍录音重点听那些AI标记为“情绪强烈”的片段。这样既节省了时间又保证了洞察的深度。3.3 一个具体的验证案例说一个具体的例子。当时我想给一个工具加一个“智能推荐”功能想法是让AI根据用户的历史操作推荐下一步动作。用AI辅助我大概花了半天时间做出了一个能用的原型。拿给用户测试的时候我发现了一个之前完全没想到的问题用户根本不看推荐。不是推荐不准而是他们压根没注意到那个推荐区域。因为他们的注意力完全集中在主操作区推荐区域在视觉上被忽略了。这个发现让我重新思考了整个功能的定位。后来我把推荐从“独立区域”改成了“嵌入到主操作流程中的提示”效果好了很多。如果按照以前的开发节奏我可能会花两周把这个功能完整做出来然后上线后发现没人用。现在半天做原型一天做测试两天就调整了方向。这里的关键经验是AI加速的是“做”的过程但“看”和“想”的过程一点都不能省。甚至因为做得快了你更需要刻意留出观察和思考的时间。4. 产品决策的权重重新分配4.1 功能优先级的判断逻辑变了以前排优先级通常会考虑“实现成本”这个维度。一个功能如果实现成本高即使价值不错也可能被排到后面。但在AI辅助开发的环境下实现成本这个维度的权重应该大幅降低。我现在排优先级主要看三个维度用户价值、验证成本、维护成本。用户价值不用多说这是根本。验证成本是指我需要花多少精力才能确认这个功能是否真的有用。维护成本是指这个功能上线之后我需要持续投入多少资源来保证它正常运行。实现成本为什么权重降低因为AI能帮你快速实现但快速实现不等于没有成本。代码写出来之后测试、调试、部署、监控、修bug这些环节的成本并没有因为AI而显著降低。所以我现在更关注的是“这个功能上线后我能不能hold住”。4.2 从“能不能做”到“该不该做”AI让“能不能做”这个问题变得不那么重要了。大部分功能只要你能描述清楚AI都能帮你做出一个版本。但“该不该做”这个问题反而变得更加关键。我见过太多团队因为AI能快速实现就疯狂加功能。结果产品变得越来越臃肿用户越来越困惑维护越来越困难。这就像给一个已经吃饱的人不停上菜看起来丰盛实际上是一种浪费。我的判断标准很简单如果这个功能不能直接帮助用户完成核心任务或者不能显著提升核心体验那就先不做。这个标准听起来很朴素但在AI能快速实现一切的环境下坚持这个标准反而需要更大的定力。4.3 一个决策框架的调整我把自己用的决策框架调整成了这样维度以前权重现在权重说明用户价值高高不变始终是核心实现成本高低AI大幅降低了实现门槛验证成本中高快速原型让验证更频繁但观察需要刻意投入维护成本中高代码量增加后维护负担显著上升战略契合中高功能越多越需要聚焦核心方向这个框架不是绝对的但对我来说它帮助我在AI辅助开发的环境下保持了对产品方向的清醒判断。5. 实操中的具体方法和避坑指南5.1 我的AI辅助开发工作流经过一年多的摸索我形成了一套相对稳定的工作流。分享出来供参考但请注意这套流程是基于我个人的项目特点和习惯你需要根据自己的情况调整。第一步需求拆解。拿到一个需求先不急着写代码而是用自然语言把需求拆成若干个可独立验证的小块。每个小块都要有明确的输入、输出和验收标准。这一步我通常自己完成因为AI容易把需求拆得太细或太粗。第二步原型生成。对于每个小块用AI生成一个最小可运行的原型。这个原型不需要考虑代码质量只要能跑通就行。目的是快速验证想法。第三步人工审查。AI生成的原型我会快速过一遍重点看逻辑是否正确、边界情况是否处理、有没有明显的安全问题。这一步不能省因为AI有时候会生成看起来合理但实际上有问题的代码。第四步重构与整合。把验证通过的原型按照项目的整体架构进行重构和整合。这一步我通常自己动手或者让AI辅助但由我把控方向。第五步测试与部署。写测试用例跑通测试部署上线。测试用例可以让AI生成初版但我会补充边界情况和异常场景。5.2 常见问题与排查技巧在实际操作中我遇到了一些高频问题整理成速查表问题现象可能原因排查方法解决思路AI生成的代码跑不通依赖缺失或版本不匹配检查import和package版本明确指定依赖版本逻辑看起来对但结果不对边界条件处理错误用极端输入测试补充边界测试用例代码风格不一致多次生成缺乏统一约束检查命名和结构制定代码规范并注入提示性能不达预期算法复杂度高或资源泄漏profiling工具分析优化关键路径集成后出现奇怪bug模块间接口不匹配检查数据流和类型统一接口定义特别提醒AI生成的代码永远不要直接上生产环境。哪怕它看起来再完美也要经过人工审查和测试。我踩过好几次坑都是因为觉得“这段代码很简单应该没问题”结果上线后出了各种意料之外的问题。5.3 几个让我印象深刻的坑坑一过度信任AI的“最佳实践”。AI会倾向于生成它见过的“标准”写法但这些写法不一定适合你的项目。比如它可能会给你生成一个复杂的抽象层而你的项目其实只需要一个简单的函数。我的应对方法是在提示里明确说明项目的规模和复杂度让AI根据实际情况调整方案。坑二忽略代码的可读性。AI生成的代码有时候会过于紧凑或者使用一些不常见的写法。这些代码机器能跑但人看起来费劲。我现在会要求AI在生成代码时加上清晰的注释并且避免过度使用语言特性。坑三测试覆盖不足。AI生成的测试用例往往只覆盖正常路径对异常路径和边界情况的覆盖不够。我现在会专门让AI生成异常场景的测试然后自己再补充一些。坑四安全漏洞。AI可能会生成存在安全风险的代码比如SQL注入、XSS、不安全的反序列化等。这个问题在Web开发中尤其突出。我的做法是所有涉及用户输入和外部数据的地方都要人工审查一遍。6. 对“做产品”这件事的重新理解6.1 产品经理和工程师的边界在模糊以前做产品产品经理负责想清楚要做什么工程师负责实现。这个分工在AI辅助开发的环境下变得越来越模糊。因为当实现变得容易的时候产品经理也可以快速做出原型来验证想法工程师也可以更深入地参与产品决策。我自己的角色就在这个模糊地带。我既要想产品方向又要动手实现还要做用户验证。这种角色融合有好处也有挑战。好处是决策链条短反馈快。挑战是容易陷入细节失去全局视角。我的应对方法是刻意切换视角。做产品决策的时候强迫自己不看代码写代码的时候强迫自己不想产品。虽然实际上很难完全分开但这种刻意的切换能帮助我保持清醒。6.2 速度与质量的平衡点在哪里AI让开发速度大幅提升但质量呢我的观察是AI能帮你快速达到“能用”的水平但从“能用”到“好用”仍然需要大量的人工投入。“能用”意味着功能跑通了没有明显bug。“好用”意味着性能达标、体验流畅、边界情况处理得当、代码可维护。这中间的差距AI能帮你缩短但不能帮你消除。我现在会把“能用”和“好用”分开对待。先用AI快速做到“能用”验证方向是否正确。如果方向对了再投入精力打磨到“好用”。如果方向错了快速放弃损失也不大。6.3 什么才是真正稀缺的能力这一年多下来我越来越觉得在AI辅助开发的环境下真正稀缺的能力是判断力。判断什么需求值得做判断什么方案更合适判断什么时候该停下来判断什么代码该重写判断什么功能该砍掉。这些判断AI能提供参考但不能替你决策。另一个稀缺的能力是品味。同样一个功能不同的人做出来体验可能天差地别。这种差异往往不在于技术实现而在于对细节的把握、对用户感受的理解、对整体一致性的追求。AI可以帮你实现但品味需要你自己培养。7. 一些具体的操作建议7.1 如何写出更好的AI提示经过大量实践我总结了几条写提示的经验明确上下文。告诉AI你的项目规模、技术栈、代码风格、目标用户。这些信息越具体生成的代码越贴合实际。分步骤描述。不要一次性让AI生成一个大模块而是拆成小步骤每一步都有明确的输入输出。这样生成的代码质量更高也更容易调试。提供示例。如果你有现有的代码风格或模式给AI一个示例让它照着写。这比用文字描述有效得多。要求解释。让AI在生成代码的同时解释它的设计思路和关键决策。这能帮你快速判断代码是否合理。迭代优化。第一版生成后根据结果调整提示再生成第二版。通常两到三轮就能得到比较满意的结果。7.2 代码审查的重点AI生成的代码审查时重点关注这几个方面逻辑正确性核心逻辑是否符合预期边界条件是否处理安全性是否有注入风险、权限问题、数据泄露风险性能是否有明显的性能瓶颈算法复杂度是否合理可维护性命名是否清晰结构是否合理注释是否充分一致性是否与项目现有代码风格一致7.3 什么时候不该用AI虽然我是AI辅助开发的积极实践者但有些场景我仍然坚持自己动手核心架构设计。架构决策需要考虑项目的长期演进、团队的技术栈、业务的特殊性这些AI很难全面把握。关键算法实现。涉及复杂业务逻辑或性能敏感的算法我会自己写或者至少自己设计好框架再让AI填充细节。安全相关代码。认证、授权、加密、输入验证这些安全关键的部分我会自己写并仔细审查。需要深度思考的决策。比如产品方向、技术选型、团队分工这些需要结合大量上下文和判断AI只能提供参考。8. 最后分享几个实用技巧第一个技巧建立自己的代码片段库。AI生成的代码如果质量不错就整理到自己的片段库里。下次遇到类似场景可以直接复用也可以作为提示的示例。这个习惯帮我节省了大量重复劳动。第二个技巧用AI做代码审查。除了让AI生成代码我还让它帮我审查代码。把一段代码贴给AI问它“这段代码有什么问题”往往能发现一些我自己忽略的细节。当然AI的审查结果需要你自己判断不能全信。第三个技巧定期做“代码考古”。每隔一段时间回顾一下之前AI生成的代码看看哪些还在用哪些已经废弃哪些需要重构。这个过程能帮你理解自己的开发模式也能发现一些潜在的问题。第四个技巧保持手写代码的习惯。虽然AI能帮你写大部分代码但完全依赖AI会让你的编码能力退化。我每周会刻意手写一些代码保持手感。这就像健身不能完全依赖器械徒手训练也很重要。第五个技巧记录决策日志。每次做重要决策的时候记录下当时的背景、考虑的因素、最终的选择和预期结果。过一段时间回头看能帮你校准自己的判断力。这个习惯在AI辅助开发的环境下尤其重要因为决策频率变高了没有记录很容易迷失。这一年多和AI一起写代码的经历让我对做产品这件事有了很多新的理解。有些理解是技术层面的有些是方法论层面的还有些是心态层面的。但最核心的一条是工具越强大使用工具的人越需要清醒。AI能帮你更快地到达某个地方但去哪里、为什么去、到了之后做什么这些问题永远需要你自己回答。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
