# 个人AI提效，救不了组织的低效 2026年，人工智能正式跨越了从“概率性文本生成”到“确定性自主执行”的惊人鸿沟。 前几年聊Agent，更多是在聊科幻片里的想象力：它会不会替代人类？会不会成为下一代操作系统的入口？会不会改写软件工程的底层规则？ 但今年不一样了。随着OpenClaw为代表的前沿项目掀起一阵席卷全球的“龙虾热”，Agentic AI彻底出圈。AI正在剥掉“聊天辅助工具”的外衣，演变成能端到端编排复杂工作流、自主调用外部API、甚至直接操控机器人的“数字同事”。 当浪漫的“零代码”叙事撞上残酷的工业级生产环境，真正棘手的新问题才开始浮出水面。无休止的“幻觉探索”烧毁了海量Token，松散的提示词导致多步骤任务频繁断裂，缺乏状态回滚机制的“自主执行”让企业级落地步步惊心。 狂热褪去之后，一场属于实干家的系统工程重构正在发生。 从虚拟环境里的代码生成，到物理世界里的具身智能；从从零开始的绿地项目，到企业级“棕地”系统的深水区改造——当下最紧迫的命题是：龙虾热褪去之后，我们究竟需要什么样的Agent？ ## 要点速览 关于护城河的转移：模型已经不再是竞争的绝对护城河。模型决定了Agent的下限，但确定性的工作流、交互协议、安全和治理体系，决定了Agent的上限和可落地的门槛。 关于真实开发场景：真正的挑战不在于从零开始的“绿地项目”，而是在现有的“棕地”系统上，如何靠谱地引入AI辅助修Bug、加需求，同时不破坏原有架构和功能。 关于通用与垂直之争：什么都想做的超级通用Agent，必然面临任务偏移、链路断裂和权限失控。更稳妥的形态，是在边界清晰的垂直Agent之上，再架设轻量的通用调度层。 关于评估体系的重构：判断一个Agent行不行，不能只看结果的“幸运通过”。必须追溯它的工具调用逻辑和执行过程——过程对了，结果才更容易对。 关于组织与人才的演进：如果还是按传统的角色分工，仅仅是每个人各自用AI提效，组织的整体效率几乎不会改变。AI时代真正稀缺的，是既深谙业务逻辑又懂AI工具链路的交叉型人才，以及善于利用这些复合型人才减少协作摩擦的领导。 ## 告别尝鲜，走向深水区 OpenClaw这类产品化的Agent出来已经有几个月了，很多人可能只是尝个鲜。非专业开发者可能回到了AI聊天产品，专业开发者也可能回到了Claude Code。两位近期在实际工作中使用Agent的情况如何？ 先看李明琦的情况。“龙虾”用得比较少，因为平时更多做深度研发。对于业内的人来说，小龙虾并没有那么惊艳——平时大家一直在做Agent的研发，它只是一个产品形态。但对于不太了解这个领域的人，突然有这样一个助手能快速解决通用的、简单的问题，那确实是一件好事。但对于做得比较深、比较垂直的业务，小龙虾很难满足需求。 近期主要的工作方向是Agent和机器人的操控——通过Agent去操控机器人。构建Agent，再构建一个Agent可以交互的虚拟环境，研究如何让Agent去做自进化，包括通过构建Benchmark数据集帮助它进化。这些偏深度的事情，相对较浅的小龙虾很难满足。 不过，最近接了一个人力资源项目，帮助HR部门做系统的升级与优化。他们的业务主要涉及人员盘点、绩效、奖励等，业务背景更偏向通识，使用工具也较浅层。所以在给他们搭建业务时，会用小龙虾帮他们搭建内容，让他们通过小龙虾去解决相对简单的问题——比如统计当前绩效好的人、筛选需要的人才。简单任务可以这么做，但太过深入的内容几乎就不去做了。 再看伍斌的经历。经历了三个阶段。 第一阶段是“小龙虾”刚爆火时，天天研究它，还去帮别人装。让人特别惊喜的是，小龙虾能连上手机的飞书APP——用飞书发语音命令，它就去搜新闻，或者做自动化的定时任务。这比以前在电脑上用要方便很多。 第二阶段，因为做AI辅助软件开发，关注的是“棕地”AI软件开发。什么叫棕地？就是在现有的软件系统上引入AI，帮助现有系统去修Bug、增加新需求。在AI的帮助下能够可靠地零手工编代码，让AI帮你修Bug、增功能。这不是从零开始的项目，而是棕地项目——相当于盖房子的那块地已经被翻开了、盖了一半，再拿AI进去介入。对应的“绿地”项目，就是一片地还没开垦。氛围编程一般适合绿地项目，但企业和个人开发者更关心的是：在现有系统之上怎么加入AI。 这个阶段又切回了Claude Code。因为小龙虾有一段时间Token用太多，被Claude封掉了不让用。而且搞棕地项目时，需要强一点的模型帮助分析架构，所以需要Claude这种大模型。 到第三阶段，发现最近出来了Hermes Agent。它的好处是根据你的工具调用（比如每十次调用），自动在后台优化你的Skill——相当于能越用越聪明。这一点比小龙虾强，小龙虾需要你手工主动让它做优化才能优化Skill。另外它还能连很多大模型，比如Claude，也能连Kimi模型。而且它通过CLI进到目录底下，所以现在偏向于使用Hermes Agent，在电脑上连上大模型去做开发工作。 现在不再用飞书连小龙虾了。用的是更硬核的方式：在iPhone手机上装一个叫Termius的终端工具连到电脑上，电脑上把Tmux跑起来。这样能手机发命令，看到电脑上运行的状态。电脑上干了一半，手机上也能看进度，还能切换不同的工具——OpenClaw、Claude Code、Hermes Agent都可以切。这就是现阶段的做法。 ## 什么是真正的Agent？工作流、协议与安全 每年都有很多产品化的Agent涌现。比如Manus出来的时候，大家对Agent的想象还停留在“聊天框交互+工具调用”；今年龙虾又启发了很多人的思考——大家开始聊Agent的系统化、系统工程以及Harness Engineering。 那么，什么样的东西才算真正的Agent？它和前几年熟悉的Copilot、助手、Workflow，真正的分界线在哪？如果往现实世界更推一步——比如结合机器人和物理世界——什么能力会突然变得比聊天框时代重要得多？ 从当下的观察来看，Agent下一阶段的竞争，模型之间的差异化正在变小。虽然仍有变化，但在Agent落地的全链路过程中，模型的影响力已经没那么大了。 核心判断是：模型已经不再是你竞争的护城河了。现在的壁垒在于——可落地的工作流、Agent的协议、安全和治理体系，整个链路显得更重要。模型已偏向同质化，虽然像Claude这样的模型可能还是比别的更好一些，但差距在不断缩小。 工作流和协议，才是Agent从“能跑”到“能干活”、进入真实业务必须要解决的关键问题。 第一，流程要更具确定性。比如一个客服Agent遇到不同问题应该走什么流程、调用哪些工具——这些是研发、产品和业务方需要清晰界定的，包括怎么和其他系统进行交互。这不能靠模型临场发挥，而是需要预定义的工作流。 第二，交互协议。Agent要和企业的系统、数据库等交互，需要建立一套规范统一的协议——权限协议、数据格式协议、回调机制。否则很容易出现调用失败、数据格式不兼容，甚至权限风险。像Agent去操作数据库，它需要申请授权，申请权限后，需要有人帮它确认才能往下走。这些不是靠模型优化能解决的，需要对业务的理解和工程化的沉淀。 第三，安全和治理能力。Agent目前涉及的链条比较多，安全性和治理能力非常重要，决定了Agent能不能进入核心业务。Agent是否足够安全？执行路径是否可追溯？经常遇到Agent出现幻觉，但下次再问时问题又无法复现。所以需要构建过程的Benchmark数据集，去评估它的执行过程是否会出问题，出了问题能不能追查到。 第四，隔离和回滚机制。Agent操作出了问题能不能回滚？会不会影响其他业务？如果这些问题不解决，模型能力再强，很多企业也不敢把核心业务直接交给Agent去做。 所以，模型决定了Agent的上限，但工作流、协议、安全和治理决定了Agent的下限和可落地的门槛——这才是核心竞争力的关键所在。 刚才提到的这些问题都很关键——相当于给模型套上一个结构、一个架子，或者直接叫Harness。现在有人管它叫约束，或者比作套马的马具——没有它你驾驭不了AI。 具体什么是Harness？应该分三大块。首先要明确的是，这里针对的用户对象不是做Agent的构建者（不是像做Claude Code的工程师），而是使用Claude Code去开发应用的人。 这些使用Claude Code的人，怎么样用好Harness？开发Agent的工程师有他们的Harness，叫Agent Builder Harness。而这里要说的Agent User Harness，是使用者自己的工具。 这个Harness包括三块。 第一块，要把协议、约束告诉它，包括企业中的隐性知识。这些知识以前可能写在代码里，或者在Confluence文档里，没有进入提示词。有一句话很关键：如果你的文档没有进入大模型的上下文，那等于不存在。所以需要想办法，把目前做的工作大模型必须要知道的内容给到它，做好准备工作。ThoughtWorks的一位首席工程师讲过一个词叫Feedforward（前馈）。熟悉的是Feedback（反馈），它在AI生成前，加了前馈——就是准备好提示词，把主要要点准备齐，不要遗漏重要内容。 第二块是Feedback（反馈）。模型运行完了，要看结果是否符合期望。可能需要写一些自动化测试，或者让大模型扫一下代码规范，看是否符合企业要求，然后把这些结果给到大模型。因为Agent能调工具，它现在缺的是反馈。给它反馈后，它看到自己出错了，再去调工具修改，这样就形成了一个闭环。 第三块是国内开发者特有的痛点——Token不自由。国外的Claude Opus、Claude Sonnet，国内很多人用不上，因为没有支付途径，人家也不让用。所以只能用国内偏弱一点的模型。而且国内模型现在也开始贵起来了，有些Token已经没有包月计划了，都是按Token计费。有这些制约，订阅时就要考虑成本，不能像以前用小龙虾那样瞎跑、反复返工去烧Token——那是烧不起的。所以需要考虑：如果这次大模型的配额触顶了，能不能换一个大模型，接着上一次中断的工作继续做？这就需要考虑记忆管理，记忆怎么跨大模型继续下去。 把这三块把握住，Agent就能用得很好。很多人说Agent给的内容不靠谱、有bug——但不妨先问问，前面说的那三块前馈、反馈、中间的记忆管理有没有做好？做好之后，再来评估大模型是否能满足需求。 ## 通用与垂直之争：什么任务该交给Agent？ 从工业或商业的系统视角看，一个Agent什么时候才算真正从Demo变成能上场的东西？特别是结合具身智能领域——刚起步的这个领域，做到什么程度才能真正落地？ 说到具身智能，目前的探索还处于比较初期的阶段，发展没有那么快。它不像纯软件Agent已经有一些相对成熟的产品了。具身智能还缺少很多东西——首先在数据这块就非常有限。它不像自动驾驶可以无限去造数据，做机器人的数据量很少。所以需要想办法做仿真环境的模拟，模拟数据和轨迹，造很多轨迹数据去帮助机器人。 机器人和纯软件Agent有所不同。具身智能的大脑相当于用大模型，类似于Agent进行思考、决策、规划。但在它通过智能体做探索时，还要格外加很多东西。 首先，智能体要把自然语言交互转化为具体的指标或坐标系。你不可能直接跟机器人说“往前走一步”就能操控它——机器人更多是通过坐标系来移动的。所以需要一个把自然语言对话转成坐标的过程，通过坐标把信号给到机器人，它获取信号后再去移动。 对于机器人Agent来讲，短期内只是在有限的数据和探索路径里做了一些尝试。它不像对话Agent的环境那么简单。当软件跟硬件结合时，会有很多问题。机器人在移动时会有物理反馈——遇到风险、遮挡，这些都需要做很多思考。所以整个链路比纯软件复杂得多。 在做这类Agent时，包括做机器人，前期会偏向做边界清晰、确定性更强的Agent。把边界和确定性定好，这样的Agent更容易落地一点。 很多一线团队最近都在面临一个现实：真正能落地的往往不是前几年常说的“通用超级Agent”，而是一套边界清楚、步骤清楚、结果清楚的垂直领域Agent。这也引出了一个很具体的问题：哪些任务值得交给它，哪些任务不能交？现在的用户真正需要的，是一个什么都能做的Agent，还是先把一个关键任务做好的Agent？ 这个问题非常好，相当于Agent该怎么设计或者怎么选。Agent其实由两部分组成：一部分是背后的大模型，另一部分是模型之外的一层Harness，两者结合做成了一个Agent。所以这两块需要一起来说。 根据经验，如果做棕地AI项目开发（在企业IT内部原有系统上引入Agent），可以分成两大类Agent。一类是能力强一点的Agent，比如Claude Code，后面连着Claude大模型。可以让它做架构分析、头脑风暴、读代码、出方案——比较复杂的事情用这个大模型。如果方案写好了，要动手去做的时候，就可以切换到国内的大模型，比如Qwen、Kimi或GLM。目前来说，它们都能把确定性的任务干好。还需要写好自动化测试，让它们看到反馈再去改。可以把这两块分开，各有侧重，不用让弱模型去搞复杂的事，也不用让强模型去干简单的事造成浪费。 以前的AI开发者讨论通用和垂直，现在搞Agent时，大家依然在争论通用和垂直——经历过两者，应该都有感受。 超级通用的Agent具有不确定性、高成本和难管控的特点。什么都想做的通用Agent，在真实业务里会遇到三个无法避免的问题。 第一点，任务一长容易偏移。因为是通用的，一会问这个话题，一会转到另一个话题，特别是在复杂多步骤的任务里，模型很容易偏离目标。比如做数据报表，中间可能调用错工具或理解错数据，导致结果偏差变大。 第二点，工具一多，链路容易断。通用Agent要适配不同的系统和工具，链路更复杂。任何一个环节出错都会导致任务失败，稳定性特别低。这是工作中经常遇到的，所以尽量把它限制得越可靠越好，否则不稳定会带来业务问题。 第三点，权限放开容易失控。通用Agent需要大量权限，但你不可能把所有权限都放开。一旦放开，就容易给企业带来数据泄露或误操作等安全风险。 相比之下，垂直确定性的Agent对公司来讲更好一点。它不是什么都能做，但在特定场景下更稳定可靠，能按照约束的规则完成任务。 首先，它边界清晰。比如做财务报销的Agent，或者专门做KUKA机器人咨询的Agent，会把边界限定得很清楚。其次，步骤具有确定性。比如客服工单Agent，遇到什么问题、走哪些流程、调用什么工具、回复什么话术，都提前预定义好，模型只负责执行，确定性更强。最后，结果更可控。任务结果是可以预期的，方便复盘，不会出现混乱，可以更放心地在核心业务里使用它。 所以未来的形态，是在垂直Agent之上再做一些轻量的通用调度层。不是说通用能力没用，而是它更多作为调度层，去协调多个垂直Agent。上层用通用调度层调度垂直Agent，而不是让单一的通用Agent去做所有的事——这样会更好一点。 Agent到底做到什么程度才能叫通用？在目前接手的系统里，什么样的任务天然更适合先交给Agent？什么样的任务必须先让人来兜底，或者一开始最不该先碰？ 如果整个业务偏向于通用类，不是特别垂直的领域，用通用的Agent就可以解决。如果任务没有特别强的专业属性，也可以优先通用的。但之前做过医疗、金融这类垂直行业，深度内容理解还是需要垂直的Agent解决起来更好。像是通用财务知识的简单计算，优先用通用的就可以。 在开发流程中，AI实际上更适合扮演通用的“实习生”角色，还是明确分配一段工序让它去干好？ 在软件开发领域，大家对通用和垂直有不同的理解。在使用过程中，通用的Agent更多使用Claude Code。现在不光用Claude Code写代码，还用它写自媒体文章，也是一把好手。它能去网上搜新闻，替代了搜索引擎，能帮忙搜东西、写会议纪要、写PPT大纲。从这个角度看，它就是一个通用的Agent。虽然Claude Code在编程领域很有名，但它刚出来时，很多非技术人群涌进来用它生成PPT。通用Agent的特点是能做很多事情，只要把前馈跟反馈做好，就能得到想要的结果。 关于垂直的Agent，取决于给它定义的角色。现在Harness有很多不同的实现方法。最近看到一篇论文，讲亚马逊的工程师怎么让Harness发挥好效果。他设计了一个框架，里面有两个角色（两个Agent）：一个叫Builder，负责构建软件；另一个叫Reviewer，负责评审软件。这两个Agent相互制衡——一个人做完另一个人去审，审完提供反馈，前面的人再去改。各干各的角色去完成质量要求比较高的任务，需要这种提供反馈的Agent去做好垂直的事情。 ## 评估与避坑：不只看结果，更要看执行过程 真到了具体的业务现场，Agent最容易卡住的地方，到底是当下的模型能力不够，还是吃不到有用的数据或业务信息？ 最近遇到了几个Case。 首先，如果问题没太理解好，Agent会出现无休止的探索。所以要对它的探索进行约束，帮它找到最优路径。遇到的情况是它出现无限次探索，需要定义在什么情况下它应该执行结束，不应该再探索了。 第二个问题是，在探索过程中是按步骤执行的，有时候步骤会出现错乱。有些不该执行的步骤它执行了——这种情况怎么控制？这也是遇到的问题。 第三个问题是，Agent的澄清能力和拒识能力没那么强。问一些和垂直领域相关的问题，它答得挺好，但如果问得太发散，很容易诱导它答出别的内容。怎么给它做拒识、帮它更好地澄清，也是大问题。 目前发现的问题，主要还来源于怎么构建更好的自动化测试集和Benchmark，不断去测出Agent的问题。短期内发现了这几项问题，也在想新的技术方案去解决。 Agent出现问题往往不是因为模型不够强，而是任务一拉长、链路一变多，它就会无限制地探索，整个状态就慢慢飘了——这个问题很重要。 有的小伙伴不知道，两个不同的任务中间需要敲一个“/new”，新开一个Session，让上下文清空。有些人没这习惯，一股脑什么都放进去，后来就会越来越飘。 基于国内Token不自由的开发者场景，经常要换大模型——因为配额满了就得换。所以很在意这次会话到底让它干什么事，和上次会话有没有关联。如果没有关联，就敲一个“/new”新开Session，清空Context。 还有一个好的实践：去插件市场找一个能可视化当前上下文使用量的工具。比如Claude Code有个进度条，告诉你目前会话的Context用了百分之多少，今天的配额还剩多少，这周的配额还剩多少——一目了然。这样就很清楚，这次会话不要超过50%。超过50%之后就可能后面就会飘了，要想办法赶紧收尾或者换下一个话题。所以把任务拆得很碎，每个任务都能独立让它去做，不会依赖前面的内容。 前面讲到的Hermes Agent有个好处——它能自动压缩上下文。有些小伙伴不爱敲“/new”，Hermes提供了一个机制：上下文快满时会自动帮你压缩。当然压缩质量有好有坏，有时候可能会把重要的事压缩掉。所以还是得把握在自己手里，控制好输入的内容，让上下文能承载要让它做的事。这样能防止Agent飘，让它每次都很精准地回答问题。 接下来聊评估标准。大家现在越来越容易感受到一件事：有些Agent最后虽然把结果做出来了，中间却全靠侥幸和运气。 真正值得探讨的问题是：它不仅要成，还要“靠谱地成”，下一次还要能同样跑好这个任务。如果要判断一个Agent到底好不好用，先看什么？真正好用的AI Agent应该关注哪些指标？ Agent好不好用，在不同的业务领域，业务目标不同，评估也会有变化。举个例子，现在做的是通过对话方式操控机器人的交互。对当前Agent的评估，首先会看它在执行任务的过程——比较看重过程。 假如是一个机器人点动任务，需要执行哪个机械臂，要看它过程是不是对的：它有没有先获取权限？获取完权限后，有没有设置速度？然后再移动轴？会对工具调用和执行过程进行追溯。因为过程对了，结果才更容易对。所以首先看过程的满足，最后才看结果的满足。 会拆成两块：一块是评估执行过程，以及执行过程之后状态的变化——这是比较直接、关键的东西。另一块是回答问题的质量。在这个场景会分成这两块。内容方面包括质量、是否回答了当前问题、是否有一些引导和步骤解析。这是从内容角度制定的细粒度指标。所以当前主要关注这两部分：执行过程及状态变化，以及回答内容的质量。 虚拟环境里跑通和真实世界里可行，这中间最容易被忽略的差距是什么？ 最容易忽略的是：虚拟环境仅仅只是模拟的真实环境。只能模拟特定的实体和核心功能，特别细微的东西很难模拟全。就像模拟一个人，只能把身体的大概部位做出来，毛细血管等细微的东西很难模拟。所以在模拟机器人场景和环境交互时，只能先把实体找出来，把实体之间的关系（类似于知识图谱）模拟出来，构建成一个环境系统。Agent就是跟这个虚拟环境交互去产生数据。 前期先构建简单的虚拟环境，随着业务丰富再不断添加。有了虚拟环境、Benchmark和Agent这三个东西后，它们就可以自动联动优化，越做越好。真实场景里没有太多真实数据，只能通过这三种方式让它朝着更好的方向自进化。发现环境问题去优化环境，发现Agent问题去优化Agent，发现Benchmark问题去丰富测试集。从这三个圈层一起优化，就会越来越好。 很多团队在把Agent接进业务时，最先要定清楚的可能是权限、责任以及组织之间的调度。如果AI已经进入研发流程，最先需要建立什么样的能力？ 这是目前软件开发行业都在面临的一个很大的问题。AI什么都能干——需求分析、架构设计、概要设计、详细编码、测试、运维——它都能干。这个时候是不是还是按照原来的没有AI时的组织机制？还是那些角色？产品经理、业务分析人员、开发、测试、运维——这些角色是不是还像AI爆发前那样设置？ 如果跨角色协作时，还是像以前那样等待的话，那几乎没有什么成效。因为在去年DORA的AI报告里已经看到了这个调查结果：组织感觉AI提效几乎感觉不到，个人程序员觉得提效个20%，但实际度量起来个人提效也就是10%左右。所以，组织机制如果没有做好引入AI后减少跨角色协作摩擦（比如一人身兼数职），业务不懂研发，研发不懂业务——那还是跟以前一样，没什么太大效果。 那什么样才能变得好呢？可以从OpenAI三个工程师五个月生成100万行代码、软件在组织内部几百人在用的场景中得到一些启发。什么意思？就是说这三个人可能会兼顾很多角色——一个人既是产品经理，又是开发人员，又是测试人员，还可能也干运维。相当于这三个人就把原先的四五个角色都做了，而且让AI帮他们零手写代码，全让AI生产代码。 这种角色的融合就是趋势。将来的业务和AI交叉的人才非常抢手——既懂业务又懂AI技术。有些人唱衰说初级程序员已经不需要了，那些新人该怎么办？其实新人不是傻瓜，他们也很聪明。可以在学校里面学一些传统行业的领域知识，同时辅修一些AI的工具。进企业之后就可以去填充缺口很大的业务跟技术交叉的人才——现在是非常非常缺的。如果有人看准了这个方向，这就是将来一个非常好的就业机会。 ## 未来的机会属于模型厂商，还是产品公司？ 今天很多Agent产品的Demo一眼看上去很惊艳。正所谓外行看热闹，内行看门道——看到这样的Demo，或者真正上手测试时，一般先看什么专业技术点？开始警惕通常是从哪个信号开始的？ 如果让AI帮忙生成软件或代码，首先会让他做一个头脑风暴，做一些架构或方案的生成。比如生成三个方案，从中挑一个。一上来不会让他直接生成一个结果——那是去年写《氛围编程》那本书时的套路了。但到了棕地开发阶段，它能操作工具且有很多权限，就不能放任自流让它去干活了，需要小步让它去做。通过一小步就能看出来它是不是做得好。 判断它是不是“金玉其外败絮其中”，经验是看每一步的检查点，定义好怎么去验收。比如架构分析，它应该给出一个能看懂的架构图——这是最基本的，如果出不来就走不下去。所以观点是：先想好怎么验收任务，定义好之后再让它去做，做完看是否符合期望。 在机器人领域也经常会看到很棒的演示视频。外行看这些机器人各有各的酷炫之处，内行是怎么看的？ 内行看机器人的话，像宇树科技的机器人可能更多是跳舞类的。现在做机器人主要是智能家居类——比如在厨房拿东西、炒菜，还有叠衣服的机器人。整体来讲，它还是挺笨的。每天要去反反复复地测、收集数据，每天用机械臂一点点叠衣服去收集数据。整体进化没有那么快，至少在家居领域还没有跑得那么好。 它不像纯智能体——智能体整体可以偏向很强的自动化。它写出来的东西，如果不仔细看，整体逻辑上看不出问题，特别是实现一个很小的业务功能点时，几乎没问题。但区别在于，当你做一个企业级项目、实现复杂功能点时，它写的代码就没那么好了——很难写出高内聚、低耦合的企业级代码。所以在做大项目时，通常先把复杂任务拆解，让它先写需求文档或设计文档。然后在文档基础上去评估哪里不足、哪里需要补充、该用什么框架逻辑，给它更细粒度的指令。需求文档改得没问题后，再让它生成代码。生成完后还是需要人工做质检，否则会有问题。 对于程序员和研发人员来讲，更多的精力不在于写代码，而在于审核AI给出的东西是不是靠谱。它可能完成80%，在80%的基础上去帮它完善，激发它达到90%甚至更高的靠谱率，再让它进一步落地。也在帮助其他团队更好使用AI提效——大家是相互合作、共同进步的过程。整个工作范式和工作内容的重心发生了迁移和变化，有了新的视角。这让做的事变得更新鲜，不像以前做研发的只做研发，现在有了角色的变化。 下一阶段的Agent，大家都在争什么？是单点能力，还是整个生态的位置？未来的机会，更属于模型公司，还是属于更懂场景的产品公司？ 过去大模型刚火那一波，出现了很多产品公司，但随着模型能力的迭代（比如OpenAI去年Image-4o的图像生成能力升级，还有今年的Claude Design和OpenAI的Image-2），很多产品公司受到了降维打击。现在模型公司和产品公司似乎处于一个非常微妙的态势。 技术做得好不好，通过产品形态去展示是非常合理的。就像苹果，大家觉得它体验好，自然觉得它的技术好。技术再好，如果没有好的产品，就看不到真实的价值。所以技术是需要产品去承载的。技术要嵌在产品里，产品尽可能满足用户痛点，大家才愿意付费。经常讲：产品做得好不好，用户愿意付费的产品就是值得用的。 看过很多研发人员技术能力很强，一两个月就能把产品上线。但如果没有把握住用户需求，又不会运营，可能就没人用了。所以大家做技术、做产品时，要看是否捕捉到了市场和用户的痛点，填补了哪块市场空白，而这块空白又是用户非常需要的。这样的产品更容易脱颖而出，否则很多产品会死在实验室里。要多做能让用户或企业快速用起来的东西。这是一个需要反馈的过程——技术和产品做得好，都需要用户和企业的反馈。只有有人用，不断提供反馈信息，才能形成闭环转起来。整个生态链少一环，都很难完整转起来。 未来还会不断有小的产品出来，因为现在做一个产品的成本已经没那么高了。可能会经常出现一些小的爆品，满足特定用户的需求。做产品的成本不高，但带来的价值还是挺大的。 有些大模型厂商把单点做得很惊艳让大家去用——这一点都不担心，因为只是单点，没有解决日常生活的痛点。比方说为什么Manus没火而是OpenClaw火了？ 有一个很重要的点，使用Manus需要把资料上传，要让它生成PPT，要把素材上传——这很麻烦。但OpenClaw是默认安装在电脑本机的。里头就有你的文件，只需告诉OpenClaw，说电脑里的这个文件需要转写成另外一种PPT。这样就不需要反复繁琐上传文件，相当于你的数据就是你自己的。但如果把数据上传到Manus，这东西归Manus了——将来是否安全，这是个问题。所以产品懂人的心理非常重要。 包括刚才说到国内Token不自由的开发者的痛点——现在没看到国内厂商专注做这个事情。如果有些厂商发现这些痛点，做一些解决痛点的事情，比如切换模型、自动路由到恰好够用的模型——这也是一个非常好的产品，很多人愿意用。 Agent这个词大家已经说了很久，但真正值得聊的部分可能今天才刚刚开始。很多人今年才开始大规模使用Agent，一开始还是用Chatbot的方式对待它，关注它的模型能力。但当它真正落地时，不得不问：它能不能更稳、更可控？能不能真的进系统、带来结果？ Agent的下一阶段拼的未必是“更像人”或者模型本身的能力，而是系统工程能力。