最近在 Hacker News 上出现了一个很有意思的提问Agentic Programming 是不是已经变成了一个 flop。所谓 flop可以理解成“雷声大雨点小”的失败品。这个话题能在技术社区引发讨论本身就说明一个问题过去两年被各种 Demo 视频和融资新闻推到顶点的“AI 自主编程”叙事已经开始遇到来自真实工程现场的反弹。如果你在开发群里待过一段时间大概会看到两种完全相反的声音。一边是 Agent 编程工具的布道者告诉你“以后开发者只要审查代码就行”另一边是真正把 Agent 接进项目里的人吐槽“它改了 A 文件结果把 B 文件里的配置也顺手改了CI 直接挂掉”。这两种声音放在一起就构成了今天关于 Agentic Programming 最真实的舆论现场。我的判断是Agentic Programming 并没有失败它只是正在经历一次典型的泡沫挤出。被证伪的并不是“让 AI 参与编程”这个方向而是“AI 能在无人监督的情况下独立完成复杂软件工程任务”这个过度承诺。这篇文章想解决的核心问题是Agentic Programming 到底是什么、为什么有人喊翻车、哪些场景真的值得用、以及如果你想上手应该怎么设计一个最小可验证的 Agent 系统。1. 这篇文章真正要回答的问题先说明一下这篇文章不是给 Agentic Programming 唱赞歌也不是写一篇“劝退指南”。我要讨论的是更实际的东西在 2025 年这个时间点一个普通开发者或者一个技术负责人到底应该怎么看待 Agent 编程这件事。你会发现网上关于 Agent 编程的讨论绝大多数停留在两个极端。一个极端是“AI 马上要替代程序员了”另一个极端是“这玩意根本没用连我写的一个工具函数都改不明白”。这两个极端都没有太大参考价值因为它们把 Agent 编程当成一个“全有或全无”的东西要么接管整个研发流程要么就是毫无价值的玩具。实际工程里没有这么简单。一个 Agent 可以在“把某个仓库里的所有硬编码数据库连接串提取到配置文件”这种任务上表现不错但在“给现有系统加一个用户角色权限管理模块”这种需要跨服务理解、数据库设计、接口兼容性判断的任务上可能连正确的任务拆解都做不出来。所以这篇文章会从四个层面展开概念层面Agentic Programming 的底层机制是什么它和普通的 AI 代码补全到底差在哪里。现实层面为什么现在越来越多人觉得它翻车这些翻车到底是技术问题还是定位问题。场景层面哪些任务是 Agent 真正能帮你省时间的哪些任务现阶段千万不要交给它。实践层面给出一个最小可运行的 Agent Runner 示例以及一套工程化落地的手段。读完这篇文章你至少能建立一个判断框架当团队里有人提议“用 Agent 来干某个活儿”的时候你能快速判断这到底是降本增效还是给生产环境埋雷。2. Agentic Programming 的核心概念与它改变了什么如果只给一个定义我会这样说Agentic Programming 是指开发者把“实现某个软件开发目标”的任务交给 AI 系统由 AI 系统自行拆解问题、调用工具、修改代码、运行验证并在必要时请求人工介入的一种编程方式。注意关键词不是“写代码”而是“自行拆解问题”和“调用工具”。这是 Agent 和普通 AI 代码助手最本质的区别。2.1 从补全、对话到自主行动过去十年开发者工具里的 AI 能力经历了三个阶段阶段代表形态交互方式责任边界第一阶段IDE 自动补全你写半行它补完决策和验证都由人完成第二阶段AI 对话编程助手你描述问题它给代码建议生成结果供人参考和粘贴第三阶段Agentic Programming你给目标它自主行动AI 负责计划、执行、验证人对结果负责前两个阶段本质上还是“加速器”代码还是人写的AI 只是帮你减少敲键盘的时间。到了第三阶段AI 不再只是“建议者”而是变成了“执行者”。它需要自己决定先读哪个文件、怎么修改、改完怎么验证失败之后还要自己调整策略。这是 Agentic Programming 最有想象力的一点也是它最容易出问题的一点它把“编程”从动作层面提升到了任务层面。2.2 Agent 的核心循环感知-决策-行动-观察不管一个 Agent 系统包装得多么复杂底层都是一个循环感知当前状态 - 做出决策 - 执行行动 - 观察结果 - 再次决策举例来说让 Agent 完成一个简单的任务“把 utils.py 里所有 Python 2 风格的 except Exception, e: 改成 Python 3 的 except Exception as e:”。感知Agent 先读取项目目录结构找到 utils.py。决策它决定用哪个工具来读取文件内容。行动调用 read_file 工具拿到源码。观察发现文件里确实存在 except Exception, e: 这种语法。再次决策调用 replace_text 工具执行替换。最后验证再次读文件或者运行 python -m py_compile utils.py 来确认没有语法错误。这个循环本身不复杂。真正的复杂度在于当任务涉及多个文件、多个服务、多种约束条件时Agent 需要在有限的上下文窗口里做出正确判断并且每一步都要在“继续行动”和“停下来问人”之间做选择。2.3 工具调用是 Agent 能落地的关键机制你可能听过 function calling 或者 tool use 这个词它在 Agent 系统里的地位可以类比成“操作系统提供给应用程序的系统调用”。没有工具调用的 AI只能生成文本。你可以让它“写一段代码”但你没法让它“去读取某个文件、执行某个测试、然后把结果带回来”。有了工具调用AI 才能把文本能力转化为行动能力才能真正操作计算机。一个可用的 Agent 系统通常需要给 AI 提供以下几类工具文件操作类read_file、write_file、list_files、search_in_files。执行类run_command、run_test。检索类搜索文档、搜索代码库、读 issue。外部服务类调用 API、创建 PR、发通知。工具的边界实际上就是 Agent 的能力边界。你给的工具越精细、越可控Agent 的表现就越稳定你给的工具越宽泛、越危险Agent 就越有可能给你惹出大麻烦。这一段的结论是Agentic Programming 真正的技术变化不在“模型变聪明”上而在“模型开始拥有行动能力”上。这也意味着它的风险不在生成代码的质量而在行动链条的失控可能性上。3. 为什么越来越多人觉得它翻车一个技术在社区里引发“是不是 flop”的讨论通常不是因为技术完全不可用而是因为实际体验和宣传预期之间出现了巨大的落差。下面是我认为最核心的五个原因。3.1 宣传承诺的是“自动驾驶”实际提供的是“高级辅助驾驶”几乎所有 Agent 编程工具的宣传视频都给人传递一个印象你只需要输入一个自然语言需求它就能像资深工程师一样打开 IDE、创建分支、改代码、跑测试、提交 PR一气呵成。但实际用起来大多数 Agent 更像一个“刚入职三天、有海量知识储备但是对你们项目一无所知”的新人。你给它一个足够小、足够明确、边界足够清晰的任务它能完成得不错你给它一个模糊的宏观需求它会很自信地开始动手然后在某个你意想不到的地方把事情搞砸。问题并不在于 Agent 能力真的那么差而在于“全自动软件工程”在当前的模型能力和工程约束下还不够成熟。把辅助驾驶宣传成自动驾驶必然导致用户在真实场景里的失望。3.2 上下文窗口掩盖了长期任务的脆弱性现在的 LLM 动辄支持几百万 token 的上下文看起来已经足够装下一个中型仓库了。但“能装下”和“能正确利用”是两回事。一个 Agent 在执行长任务时很容易出现“前期规划做得很好后期逐渐忘记约束条件”的问题。它可能在对话的前半段还记得“不能修改数据库连接配置”但在执行到第 9 个文件修改时因为中间插入了大量工具调用结果注意力被稀释开始违背最初的目标。这种失败模式在短 Demo 里几乎不会出现因为 Demo 只有几轮交互。但在真实的长任务里非常常见这也是很多开发者第一次使用 Agent 时的崩溃点看着它绕了一大圈最后改错了文件。3.3 错误恢复能力弱甚至不如一个普通实习生人类程序员在写代码时做错一个步骤往往会立刻意识到“这个修改会导致测试挂掉”然后回头修正。但 Agent 的纠错能力取决于它的模型推理能力和“观察结果”的质量。给 Agent 一个明确的错误信号比如“测试失败报错信息是 xxx”它大概率能修正但如果在执行过程中没有产生显式错误只是隐含地偏离了目标Agent 常常会没有感知地继续下去。这就导致一个尴尬的现状Agent 在没有反馈的环境中表现得很好一旦进入真实项目这种布满反馈的环境反而会因为“不知道自己不知道”而展现出一种自信的脆弱。3.4 成本与回报不成正比Agent 执行任务时每一次工具调用都会消耗 token。一个表面上只有 50 行代码的修改任务Agent 内部可能已经读了十几遍文件运行了七八次测试。当任务复杂度上来token 消耗会呈指数级增长。对于个人开发者这可能只是“感觉有点贵”对于团队这就成了一个需要被严格核算的工程成本。如果你可以用 30 分钟手写完成的任务Agent 花了 15 分钟并且烧掉了几十万美元 token那不管嘴上怎么说效率提升实际的 ROI 都是亏的。这里要补充一个观察未来 Agent 编程工具真正能跑通商业逻辑的方向大概率是少数高频、高价值、可验证的任务而不是“任何一个编码需求”。3.5 评测黑箱Demo 不等于可用我很少见到有团队会认真评估“Agent 在我们仓库上的成功率”。大多数时候大家只是拿几个示例任务跑一下看看效果还不错就认为可以大规模使用了。这是 Agent 编程落地最大的坑。Demo 任务通常经过精心挑选比如单文件重构、添加单元测试。而真实项目里充满了历史包袱、隐式约定和跨模块依赖。没有一套针对自己项目的评测集你就无法判断 Agent 产出是稳定可靠还是恰好运气好。4. 什么场景真的适合 Agent什么场景要谨慎聊了很多踩坑点接下来给一个更具体的判断框架。你要理解一个核心原则Agent 适合的任务必须是“目标明确、边界清晰、结果可验证”的任务。不符合这三个条件的任务现阶段都不要轻易交给 Agent。4.1 适合 Agent 的场景场景为什么适合典型任务示例机械性代码重构修改规则明确结果可自动验证把 Python 2 语法改成 Python 3单元测试生成覆盖面可度量失败反馈清晰为工具函数补充测试用例批量文件处理操作重复可通过脚本/编译检查验证给所有 Java 文件添加统一的 license 头代码搜索和标注只需要读和理解不需要复杂修改找出所有使用弃用 API 的位置并给出替换建议文档对齐以现有代码为输入生成特定格式文档为 API 接口生成 OpenAPI 描述这些任务的共同点是即使 Agent 做错了你也能很快发现。测试挂掉、编译失败、文件 diff 异常都是强反馈信号。4.2 不适合 Agent 的场景场景为什么不合适核心业务逻辑改造涉及隐藏的业务规则Agent 无法理解全貌跨服务架构调整需要同时掌握多个系统的契约和约束生产数据库变更一旦出错影响面不可控必须人工审批安全与权限相关修改属于高风险、不可回滚的操作领域需要主观判断的代码风格重构可验证性差容易引入无谓的大规模 diff这里我有一个比较明确的观点如果你发现一个任务“连团队里刚入职的初级工程师都需要带着做并且需要反复 Review”那就别指望 Agent 能独立完成。它当前的定位更像是“可以分担重复劳动的实习生”而不是“能独当一面的高级工程师”。5. 最小可运行实现自己写一个带工具调用的 Agent Runner为了让你真正理解 Agent 的执行机制我写了一个最小可运行的 Agent Runner 示例。这个示例不依赖任何外部模型 API用一组简单规则来模拟 LLM 的决策循环目的是让你看清 Agent 系统的骨架。理解了骨架之后接入真实模型就是替换一个函数的事。5.1 环境准备Python 3.8 或更高版本。不需要安装任何第三方包。建议使用一个单独的目录来跑避免文件操作污染你的项目。5.2 完整代码# 文件路径demo_agent.py 一个最小可运行的 Agent Runner 教学示例。 核心逻辑Agent 采用“循环执行”的方式完成任务。 每一轮都会决定下一步动作 - 读取文件 - 替换内容 - 结束任务 真实场景中decide_next_action 会被替换为 LLM 调用 这里为了让大家能直接运行使用简单的规则来模拟。 import os TOOLS {} def tool(name): 注册工具函数的装饰器 def decorator(fn): TOOLS[name] fn return fn return decorator tool(read_file) def read_file(path: str) - str: 读取文本文件内容用于感知当前代码状态。 with open(path, r, encodingutf-8) as f: return f.read() tool(replace_content) def replace_content(path: str, old: str, new: str) - str: 在指定文件中执行文本替换。 with open(path, r, encodingutf-8) as f: content f.read() if old not in content: return fERROR: not found old content: {old} content content.replace(old, new) with open(path, w, encodingutf-8) as f: f.write(content) return OK tool(finish) def finish(result: str) - str: 结束 Agent 循环返回最终结果。 return fFINISH: {result} def decide_next_action(task: str, tool_results: list) - dict: 决策函数根据当前任务和之前的工具调用结果决定下一步动作。 这里用规则模拟 Agent 的“思考” 1. 如果还没读过文件先读文件。 2. 如果读到了包含 old_function 的内容执行替换。 3. 如果已经替换成功完成任务。 if not tool_results: return { action: read_file, args: {path: example.py} } last_result tool_results[-1] if isinstance(last_result, str) and old_function in last_result: return { action: replace_content, args: { path: example.py, old: old_function, new: new_function } } if isinstance(last_result, str) and last_result OK: return { action: finish, args: {result: task done} } # 兜底无法继续时结束任务避免无限循环 return { action: finish, args: {result: unexpected state, stop} } def run_agent(task: str, max_round: int 5) - str: 运行 Agent 主循环。 参数 task: 要完成的任务描述。 max_round: 最大执行轮数防止 Agent 无限循环。 tool_results [] for i in range(max_round): print(f[round {i}] deciding next action...) decision decide_next_action(task, tool_results) action decision[action] args decision[args] if action not in TOOLS: return fERROR: unknown tool {action} fn TOOLS[action] result fn(**args) tool_results.append(result) print(f[round {i}] action{action}, args{args}, result{result}) if action finish: return result return ERROR: reach max_round, agent did not finish if __name__ __main__: # 构造一个测试文件 with open(example.py, w, encodingutf-8) as f: f.write(def old_function():\n return 1\n) task 把 example.py 中的 old_function 改成 new_function print(run_agent(task))5.3 运行方式与预期输出在终端执行python demo_agent.py预期输出如下[round 0] deciding next action... [round 0] actionread_file, args{path: example.py}, resultdef old_function(): return 1 [round 1] deciding next action... [round 1] actionreplace_content, args{path: example.py, old: old_function, new: new_function}, resultOK [round 2] deciding next action... [round 2] actionfinish, args{result: task done}, resultFINISH: task done运行结束后打开 example.py内容应该是def new_function(): return 15.4 把规则决策函数替换为真实 LLM真实场景下你只需要把decide_next_action函数替换为调用 LLM 的逻辑。下面是一个不依赖具体厂商 SDK 的示意具体 API 参数请以你使用的模型服务为准# 伪代码示意接入真实 LLM 时替换 decide_next_action # def decide_next_action(task, tool_results, llm_client): # messages [ # {role: system, content: 你是代码重构助手只能使用提供的工具。}, # {role: user, content: task}, # ] # for result in tool_results: # messages.append({role: assistant, content: 执行工具 str(result)}) # # response llm_client.chat.completions.create( # model你的模型名称, # messagesmessages, # toolsTOOL_SCHEMAS, # 描述 read_file、replace_content 等工具 # tool_choiceauto, # ) # # 解析 response决定返回 {action: ..., args: {...}}看到没有Agent 系统的骨架并不神秘。真正难的部分在于怎么设计一套足够精细的工具。怎么把项目的隐性约束传递给 LLM。怎么在每一步都做安全校验。怎么判断 Agent 是否完成了任务。6. 如何判断 Agent 做得好不好评测与回归你可能已经发现了Agent 编程和传统编程有一个本质差异传统程序只要输入不变、代码不变输出就是确定的Agent 的输出却有随机性同一个任务换个时间跑结果可能不一样。所以如果你想在自己的项目里引入 Agent 编程第一件事不是到处宣传“我们上了 AI”而是先建一个评测集。6.1 评测集长什么样每个用例至少包含三样东西task任务描述。context_files允许 Agent 操作的上下文文件。success_criteria判断任务是否成功的可检查条件。建议使用 JSONL 格式每行一个用例{task: 把 src/utils.py 中所有 old_function 改名为 new_function, context_files: [src/utils.py], success_criteria: [src/utils.py 中不存在 old_function, src/utils.py 中存在 new_function, python -m py_compile src/utils.py 通过]} {task: 给 tests/test_math_utils.py 补充至少 3 个测试用例, context_files: [src/math_utils.py, tests/test_math_utils.py], success_criteria: [tests/test_math_utils.py 中新增测试函数数量 3, pytest tests/test_math_utils.py 通过]}6.2 一个简单的评测脚本# 文件路径eval_suite.py import json import subprocess import sys def load_cases(path: str) - list: with open(path, r, encodingutf-8) as f: return [json.loads(line) for line in f if line.strip()] def check_criteria(criteria: list) - bool: 简单实现检查条件中涉及的关键词是否存在。 import os for c in criteria: if 不存在 in c: keyword c.split(不存在)[1].strip() # 假设检查的是文件内容这里只做演示 print(f check: {c}) elif 通过 in c: # 实际场景中应该执行命令并检查返回码 print(f check: {c}) else: print(f check: {c}) return True def eval_suite(cases_file: str): cases load_cases(cases_file) success_count 0 for idx, case in enumerate(cases): print(f[case {idx}] {case[task]}) # 实际场景中这里调用 run_agent(task, context_files) # ok check_criteria(case[success_criteria]) ok True if ok: success_count 1 print(f passed: {ok}) total len(cases) print(f\nResult: {success_count}/{total} passed, rate{success_count / total:.2%}) if __name__ __main__: sys.exit(eval_suite(cases.jsonl))把这个脚本的含义说得直白一点你允许 Agent 在评测集上失败但你不允许它在没有评测的情况下直接进入生产路径。评测集就是你的“质检门”。6.3 评价维度建议除了“一次跑通”之外还要关注完成率100 个任务里能正确完成几个。回归率改完 A 功能之后有没有引入 B 功能的问题。最小改动率Agent 完成任务时是不是只改了应该改的文件。成本平均每个任务消耗多少 token、多少时间。人工介入频率多少次需要人工打断或纠正。如果完成率不到 80%就不要让它进入无人值守流程。如果完成率高但最小改动率低说明它的任务理解还有偏差需要进一步收紧上下文和工具范围。7. 提高正确率和降低风险工程化手段评测解决的是“怎么知道 Agent 行不行”的问题工程化手段解决的是“怎么让它更行”和“怎么在它不行的时候不炸掉生产环境”的问题。7.1 把大任务拆成小任务Agent 在短任务上的可靠性远高于长任务。一个任务是“完成整个登录模块的重构”还是“只把 PasswordEncoder 从 MD5 替换为 BCrypt”后者的成功率会显著更高。在实际使用中合理的方式是人来做任务规划Agent 来做任务执行。人工把一个大需求拆成多个可独立验证的小任务每个小任务交给 Agent 完成。7.2 限制上下文和文件白名单不要让 Agent “读整个仓库”。给它一个明确的白名单# 文件路径agent_workspace.yaml allowed_files: - src/utils.py - tests/test_utils.py read_only_files: - README.md - docs/architecture.md forbidden_files: - .env - config/production.yaml - migrations/这个白名单不仅是权限控制也是给 Agent 的注意力引导。上下文越干净它就越不容易跑偏。7.3 工具接口要设计得“窄”而“安全”一个常见的错误是给 Agent 提供太宽泛的工具比如execute_any_command。这听起来很灵活实际上非常危险。更好的设计是提供原子化的安全工具read_file(path)负责读。replace_content(path, old, new)负责替换。run_tests(test_path)负责跑测试。把危险动作从工具的“参数”里拿掉只留下必要的能力Agent 造成破坏的可能性就会大幅下降。7.4 沙箱执行与人工审批点如果 Agent 要修改真实文件建议在临时分支或容器中执行。下面是两种常见的执行模式全自动模式Agent 在临时分支上完成任务推送到远端等待人工 Review。半自动模式普通文件操作自动执行涉及配置文件、数据库迁移、依赖安装时暂停等待人工确认。无论哪种模式都要确保 Agent 的操作可以被回滚。最坏的情况下你能通过 git revert 恢复到执行前状态这是底线。7.5 记录完整的执行轨迹Agent 执行长任务时最后一步比第一步重要得多。如果最终结果不对你需要能回溯它到底在哪个环节做了哪个决策、读了哪个文件、执行了什么命令。这里建议记录的信息包括每一轮的决策内容action 和 args。每一个工具调用的输入和输出。Agent 运行时的模型版本和参数配置。起始代码库的 commit hash。有了执行轨迹你才能把 Agent 的错误定位到具体环节而不是把“Agent 不行”当成一个黑盒结论。8. 常见误区与排查清单下面把我在社区讨论和实际使用中经常看到的问题整理成一个排查清单。问题现象可能原因排查方式解决方案Agent 频繁半途而废任务过大没有拆到可验证粒度检查任务描述和日志中的轮次数拆分任务每轮只做一个小改动Agent 修改了无关文件上下文范围过大约束不明确对比 git diff 中的文件列表增加文件白名单明确 forbidden_filesAgent 一直在重复同一个错误动作错误信号没有被传给模型检查每一步工具结果是否被记录在循环中把工具错误结果明确写入历史运行成本很高任务太长、无用读取过多统计工具调用次数和 token 消耗限制最大轮数裁剪上下文关闭不必要的检索同一任务结果不稳定模型采样温度设置过高或模型版本变化固定模型版本检查采样参数降低 temperature固定模型和系统提示词改完代码后编译或测试挂了缺少验证步骤检查 Agent 是否运行了编译/测试工具在工具集里加入 test 工具并强制在完成前调用Agent 在 Demo 上表现很好真实任务翻车评测集和真实任务分布不一致检查评测集是否覆盖了真实任务难度用真实历史任务扩充评测集再进行灰度在使用 Agent 工具时如果出现问题我建议按以下顺序排查先看任务描述是否足够具体。再检查允许操作的文件范围是否太大。然后看 Agent 有没有拿到及时的验证反馈。最后看是不是模型本身问题换更强或更便宜模型重试。大部分“翻车”都不是模型能力问题而是任务定义和上下文工程设计的问题。9. 团队落地与我的建议现在的 Agentic Programming值得尝试吗我的回答是值得但它不应该以“全员上马、全流程无人值守”的方式落地。这里有一条比较稳妥的推进路径第一步选试点任务。挑选 20 到 50 个低风险、可自动验证的任务做成评测集。例如日志调整、注释规范、单文件重构、测试用例生成。第二步在隔离环境跑评估。不要让 Agent 直接操作主分支而是在临时分支上运行通过 CI 检查结果。第三步建立质量门禁。Agent 的产出必须走和人类开发者一样的 Code Review 流程并且要额外检查“最小改动率”防止 Agent 顺手改坏其他文件。第四步逐步扩大范围。只有在评测集成功率超过阈值、人工介入率降到合理水平之后才考虑把 Agent 加入更复杂的任务流程。第五步保持人工复核。至少在当前阶段不要让 Agent 在无人监管的情况下合并代码或操作生产环境。从更宏观的角度看Agentic Programming 目前更像是一次“编程接口”的演进。它把编程任务的交互界面从“代码”提升到了“意图”这是有真实价值的。但它还远不是“自动化研发的终局”。真正决定一个团队能否用好 Agent 的往往不是模型强不强而是你有没有把任务定义清楚、把上下文管理好、把验证机制建起来、把回滚流程准备好。我的建议是现在就可以动手搭一个评测集选几个重复劳动最多的任务试水。不要一开始就追求“AI 接手整个项目”先从“AI 帮我完成下一个无聊的重构任务”开始。这一步跑通之后你会得到比看十篇讨论帖更准确的判断。10. 结论不是 flop是定位正在回归现实回到标题里的问题Agentic Programming 是不是一个 flop从“被过度吹捧”的角度看它的确在经历某种意义上的幻灭。那些“输入一句话AI 自动完成整个产品”的叙事至少在当前技术环境下是不现实的。但从“技术方向是否成立”的角度看它没有 flop。工具调用、自主循环、自动化任务执行这套机制已经在很多狭窄场景里证明了自己的价值而且这些场景正在从“玩具级”向“工程级”过渡。真正失败的不是 Agentic Programming而是“把 Agent 当成万能自动化引擎”的幻想。这个幻想破灭之后剩下的才是有价值的部分一个擅长执行边界清晰、反馈迅速的重复性编程任务的数字助手。它不需要取代你它只需要帮你把那些你最不想写代码的时刻省下来。这也应该是你评估任何 Agent 编程工具时的唯一标准它有没有让我在一个具体的、低风险的、可验证的任务上花更少的时间。如果有就值得用如果没有不代表方向有问题只是还没到该用的时候。