很多人会有一种直觉AI越强Prompt就越不重要。因为以前模型能力弱的时候需要反复解释这里是什么意思。那里不能改。输出要什么格式。哪几个文件不要碰。但随着ChatGPT、Codex这类AI越来越能自主理解代码、调用工具、修改文件、运行测试似乎以后只需要说一句“把这个问题修一下。”剩下的交给AI自己完成就行。但真正开始把AI用于长任务以后会发现一个很反常识的现象AI执行能力越强“一开始把任务交代清楚”反而越重要。因为以前任务定义模糊最多得到一个不太好的回答。现在任务定义模糊AI可能会沿着这个模糊目标搜索几十个文件。修改多个模块。运行大量测试。调用Subagent。不断Retry。最后才发现它完成了很多工作但完成的不是你真正想要的工作。这意味着Agent时代真正重要的能力正在从“怎么问AI一个问题”逐渐变成Task Specification也就是怎么定义一个值得AI长期执行的任务。一、以前Prompt写错了成本很低传统聊天式AI有一个特点交互周期很短。你问一句。AI回答一句。发现不对以后重新问。成本并不高。比如你让AI“帮我重构这个函数。”它理解错了。你马上可以补一句“不要改接口只整理内部实现。”整个纠偏可能只需要几十秒。所以在这个阶段Prompt不够清晰的问题并没有那么严重。但Agent不一样。如果你告诉Codex“把这个模块重构一下顺便把相关问题处理掉。”然后让它自主执行半小时这句话里的每一个模糊词都可能被放大。“重构”到什么程度“相关问题”包括哪些能不能改接口能不能改数据库Schema测试失败以后是否允许扩大Scope什么状态才算Done如果这些都没定义AI就必须自己补答案。二、AI越自主模糊任务的“放大效应”越严重可以把Agent执行理解成一条链Task → Plan → Search → Modify → Test → Replan → Continue任务定义是最前面的输入。如果最开始目标偏了一点后面的每一步都会建立在这个偏差上。这和人工导航很像。如果起点只偏了十米可能问题不大。但如果沿着错误方向跑几十公里最后偏差会越来越大。Agent也是一样。最开始一句模糊描述可能只产生很小的理解偏差。但经过多轮Planning。大量Tool Calls。代码修改。测试。Retry。这个小偏差就会产生Error Amplification错误放大。所以Agent能力越强错误任务定义的代价反而越高。三、“做什么”已经不够了还要说明“不要做什么”很多人给AI任务时只会告诉它要做什么。比如修复订单页面加载慢的问题。但真正成熟的Task Specification通常还需要第二部分Non-goal非目标。也就是这次明确不做什么。例如不要重写整个订单模块。不要改数据库结构。不要顺手升级依赖。不要改变现有API。不要处理与当前性能问题无关的历史代码。为什么Non-goal这么重要因为AI很容易在执行过程中发现“顺便还能优化这个。”“这里也有一个问题。”“这个模块设计也不太合理。”从局部看这些判断可能完全正确。但从任务角度看它们可能正在制造Scope Creep范围膨胀。最终原本一个两小时能结束的任务变成了一个大型重构项目。四、未来最危险的Agent不是能力弱而是“很能干但方向不清楚”能力弱的AI反而容易发现。它不会。它报错。它停止。你马上就知道需要人工介入。真正危险的是能力很强而且非常积极。它会主动搜索。主动修改。主动补测试。主动处理发现的问题。如果方向正确这当然非常高效。但如果Primary Goal没有定义清楚高执行力就会变成高速度跑偏。所以未来AI开发一个非常重要的原则可能是Autonomy越高Specification也必须越强。AI越自主人就越不能只给一句模糊目标。五、一个完整任务至少需要四个东西未来给Agent派任务可能越来越像写一个小型工程Spec。不一定很长但至少应该包含四部分。第一部分Goal到底要解决什么问题例如不是“优化登录”。而是将登录接口P95响应时间从当前水平降低重点排查认证后缓存读取链路。第二部分Scope允许处理哪些范围例如认证服务。缓存层。相关测试。第三部分Constraints哪些东西不能改变例如不能修改对外API。不能改变数据库Schema。不能删除现有兼容逻辑。第四部分Done Criteria什么状态算完成例如目标测试通过。性能问题可复现并验证改善。没有新增Regression。这四个东西一旦明确Agent执行空间会立刻缩小。六、Done Criteria可能比Prompt本身还重要很多AI任务为什么会越跑越久不是因为AI不会做。而是不知道什么时候应该停。比如“帮我把这个模块优化一下。”这句话几乎没有天然终点。代码可以继续优化。测试可以继续增加。结构可以继续整理。命名可以继续改善。所以Agent很容易不断发现“还有事情可以做。”但如果任务变成修复当前缓存刷新Bug相关测试全部通过并保证公开API行为不变。终点就非常明确。这就是Done Criteria它解决的是Agent时代一个非常核心的问题Termination Condition。什么时候结束如果没有Termination Condition一个能力越来越强的Agent反而更容易无限扩展工作。七、可以建立一个指标Task Clarity Score以后判断一个任务适不适合直接交给Agent可以建立一个简单指标Task Clarity Score任务清晰度。可以看五件事目标是否明确Scope是否明确限制是否明确成功标准是否明确出现异常时是否知道如何处理如果这五项里只有一两项清楚就不适合直接让Agent长时间自主运行。如果五项大部分都清楚这个任务才真正适合Deep Execution。也就是说AI能力不是决定Agent能不能长时间跑的唯一变量。任务本身的清晰度同样重要。八、为什么大型Repository更需要清晰任务小项目里即使目标模糊AI可探索的范围也有限。十几个文件。几个模块。很快就能看完。但大型Repository不一样。可能包含几十个服务。几百个模块。历史兼容逻辑。多个测试体系。大量配置。如果你只告诉AI“检查一下这里的问题。”搜索空间可能巨大。Agent必须自己决定看哪里。忽略哪里。哪些问题相关。哪些问题值得修改。任务定义每模糊一层搜索空间就扩大一层。最终大量计算并不是花在解决问题。而是花在判断你到底想让它解决什么问题。九、任务定义清楚以后AI最大的变化是“搜索空间缩小”这其实是Task Specification真正的价值。很多人以为写清任务是为了让AI“听话一点。”更深层的作用是Search Space Reduction缩小搜索空间。例如“检查支付系统有没有问题。”搜索空间非常大。但如果变成只排查支付回调在并发重试条件下为什么偶尔重复创建订单不改支付协议层不处理其他告警。AI一开始就可以排除大量无关方向。于是Search更少。Context更干净。Hypothesis更集中。Tool Calls更有效。Retry更少。最终真正节省的是整个任务的计算成本。十、这也是为什么AI越强任务拆分反而越重要很多人认为模型足够强以后应该可以直接把一个巨大的任务整个扔进去。理论上当然可以。但工程上未必划算。例如“把整个用户系统重构一下。”这可能包含认证。权限。Profile。缓存。数据库。API。测试。迁移。如果一次全部交给Agent任务状态会快速膨胀。更合理的方式可能是拆成认证边界确认。权限模型整理。缓存层重构。API兼容验证。测试补全。每一个阶段都有独立的Done Criteria。这叫Bounded Task有边界的任务。未来AI执行能力越强真正成熟的开发者越可能追求让AI长期执行小而清晰的目标而不是长期执行巨大而模糊的目标。十一、真正好的任务描述不需要写成几千字这又是另一个误区。任务清晰不等于Prompt很长。一个很长的Prompt也可能非常混乱。真正重要的是Information Structure信息结构。比如下面这种结构目标修复购物车并发更新导致数量覆盖的问题。范围Cart Service及相关测试。不要做不改数据库Schema不重构无关模块。完成标准并发测试稳定通过现有接口行为保持不变。实际上只有几句话。但对于Agent来说它比一大段“你认真分析一下整个项目看看为什么这里有问题尽量修好并确保代码质量……”价值高得多。因为前一种提供的是决策边界。后一种提供的主要是语气。十二、未来开发者可能越来越像“任务设计师”以前开发者主要负责写代码。以后AI承担越来越多执行以后人的工作可能逐渐向前移动。从Implementation移动到Specification。也就是定义问题。划定边界。建立约束。定义验收。决定优先级。然后AI负责执行。这并不是说代码能力不重要。恰恰相反。只有真正理解系统的人才能写出高质量Task Specification。因为你必须知道什么可以改。什么不能改。风险在哪里。什么才算真正完成。所以未来高级开发者的价值可能越来越体现在把模糊业务问题转换成AI能够稳定执行的工程任务。十三、这会进一步改变团队协作方式以前一个任务可能是产品经理描述需求。开发者理解。开发者自己实现。以后可能变成产品需求。开发者转换成Agent-ready Task。Agent执行。开发者验证。这中间会出现一个新的能力层AI-ready Specification也就是专门为Agent执行准备的任务定义。谁能够把复杂问题稳定转换成这种Specification谁就能让AI承担更多真正有价值的工作。所以未来团队之间的差距可能不仅是谁用了更强模型。而是谁拥有更成熟的任务定义体系。十四、任务交代不清其实也是一种计算浪费从资源角度看模糊任务非常贵。因为AI必须自己承担目标猜测。Scope探索。优先级判断。边界判断。Done判断。每一次不确定性都会增加Search。Reasoning。Tool Calls。Retry。Context。最终你可能觉得“这个Agent怎么这么吃资源”但问题可能并不完全在模型。而在Specification Debt任务定义债务。你前面少花了5分钟把任务说清楚后面AI可能多花30分钟探索。这就是典型的把人的定义成本转化成了AI的计算成本。十五、一个很实用的五问法以后准备把一个任务长期交给Codex之前可以先问自己五个问题。第一它最终要交付什么第二允许改哪里第三明确不能改什么第四怎么判断已经完成第五如果过程中发现其他问题要不要处理这五个问题如果都能回答这个任务通常已经比较适合Agent。如果连你自己都回答不了那就不应该期待AI在执行几十分钟以后自动猜对。十六、什么时候应该让AI自己探索当然不是所有东西都必须提前定义。探索型任务本身就是合理的。比如找出这个性能问题最可能的Root Cause。这时候允许Agent搜索。但即使是探索任务也应该有边界。例如允许探索哪些模块。需要输出什么Evidence。什么时候停止探索。最多保留几个Hypothesis。也就是说探索可以开放任务不能无限开放。否则“分析问题”很容易变成无限阅读Repository。十七、为什么这件事会影响Plus和Pro的判断这也是很多用户容易忽略的地方。如果一个人的AI工作流里任务经常很模糊。Scope不断扩大。Retry很多。AI经常跑偏以后重来。那他首先遇到的可能不是真实容量不足。而是Specification效率太低。这种情况下即使升级到更高容量也只是让AI能够跑更久的错误任务。所以应该先优化Goal。Scope。Constraints。Done Criteria。十八、什么时候Plus其实已经够用如果你的日常任务主要是明确Bug。中型Feature。代码Review。测试补全。小范围重构。并且每个任务都能够提前定义清楚目标。边界。Done Criteria。那么Plus通常已经可以覆盖大量开发工作。因为清晰任务会明显减少无效探索。Scope Drift。重复Retry。错误修改。同样容量下真正完成的有效任务会更多。十九、什么时候Pro才真正开始匹配如果你已经有成熟的Task Specification流程任务边界清楚。Done Criteria稳定。低价值探索减少。Agent跑偏能够及时发现。大任务也能拆成Bounded Tasks。但每天依然存在大量高复杂度。长执行链。高价值。必须持续运行的Agent任务。而这些任务本身的有效执行率已经很高仍然频繁受到容量限制这才说明你的问题正在从Workflow Problem变成Capacity Problem这时候Pro才真正开始匹配你的实际负载。最后AI越来越强以后一个很容易产生的误判是以后我们会越来越不需要把任务说清楚。实际上可能正好相反。当AI只能回答一句话时理解偏一点影响很小。当AI可以自主工作几十分钟、修改多个文件、运行工具、调用Subagent以后任务定义里一个很小的模糊点都可能经过执行链被不断放大。所以未来真正成熟的AI开发并不是“我只说一句剩下全部让AI猜。”而是“我把目标和边界定义到足够清楚然后尽可能把执行交给AI。”AI越强人越应该少做重复执行。但与此同时人也必须越来越擅长定义目标。划定Scope。设置约束。定义Done。因为Agent时代真正昂贵的可能不再是“没人干活。”而是一个非常能干的AI花了很长时间把错误的事情做得非常漂亮。持续更新Codex、大模型开发相关技术内容。长期使用各类代码大模型整理了稳定的Plus/Pro会员订阅渠道有需要可自取
ChatGPT、Codex趋势：为什么AI越来越强以后，“一次把任务交代清楚”反而越来越重要？
很多人会有一种直觉AI越强Prompt就越不重要。因为以前模型能力弱的时候需要反复解释这里是什么意思。那里不能改。输出要什么格式。哪几个文件不要碰。但随着ChatGPT、Codex这类AI越来越能自主理解代码、调用工具、修改文件、运行测试似乎以后只需要说一句“把这个问题修一下。”剩下的交给AI自己完成就行。但真正开始把AI用于长任务以后会发现一个很反常识的现象AI执行能力越强“一开始把任务交代清楚”反而越重要。因为以前任务定义模糊最多得到一个不太好的回答。现在任务定义模糊AI可能会沿着这个模糊目标搜索几十个文件。修改多个模块。运行大量测试。调用Subagent。不断Retry。最后才发现它完成了很多工作但完成的不是你真正想要的工作。这意味着Agent时代真正重要的能力正在从“怎么问AI一个问题”逐渐变成Task Specification也就是怎么定义一个值得AI长期执行的任务。一、以前Prompt写错了成本很低传统聊天式AI有一个特点交互周期很短。你问一句。AI回答一句。发现不对以后重新问。成本并不高。比如你让AI“帮我重构这个函数。”它理解错了。你马上可以补一句“不要改接口只整理内部实现。”整个纠偏可能只需要几十秒。所以在这个阶段Prompt不够清晰的问题并没有那么严重。但Agent不一样。如果你告诉Codex“把这个模块重构一下顺便把相关问题处理掉。”然后让它自主执行半小时这句话里的每一个模糊词都可能被放大。“重构”到什么程度“相关问题”包括哪些能不能改接口能不能改数据库Schema测试失败以后是否允许扩大Scope什么状态才算Done如果这些都没定义AI就必须自己补答案。二、AI越自主模糊任务的“放大效应”越严重可以把Agent执行理解成一条链Task → Plan → Search → Modify → Test → Replan → Continue任务定义是最前面的输入。如果最开始目标偏了一点后面的每一步都会建立在这个偏差上。这和人工导航很像。如果起点只偏了十米可能问题不大。但如果沿着错误方向跑几十公里最后偏差会越来越大。Agent也是一样。最开始一句模糊描述可能只产生很小的理解偏差。但经过多轮Planning。大量Tool Calls。代码修改。测试。Retry。这个小偏差就会产生Error Amplification错误放大。所以Agent能力越强错误任务定义的代价反而越高。三、“做什么”已经不够了还要说明“不要做什么”很多人给AI任务时只会告诉它要做什么。比如修复订单页面加载慢的问题。但真正成熟的Task Specification通常还需要第二部分Non-goal非目标。也就是这次明确不做什么。例如不要重写整个订单模块。不要改数据库结构。不要顺手升级依赖。不要改变现有API。不要处理与当前性能问题无关的历史代码。为什么Non-goal这么重要因为AI很容易在执行过程中发现“顺便还能优化这个。”“这里也有一个问题。”“这个模块设计也不太合理。”从局部看这些判断可能完全正确。但从任务角度看它们可能正在制造Scope Creep范围膨胀。最终原本一个两小时能结束的任务变成了一个大型重构项目。四、未来最危险的Agent不是能力弱而是“很能干但方向不清楚”能力弱的AI反而容易发现。它不会。它报错。它停止。你马上就知道需要人工介入。真正危险的是能力很强而且非常积极。它会主动搜索。主动修改。主动补测试。主动处理发现的问题。如果方向正确这当然非常高效。但如果Primary Goal没有定义清楚高执行力就会变成高速度跑偏。所以未来AI开发一个非常重要的原则可能是Autonomy越高Specification也必须越强。AI越自主人就越不能只给一句模糊目标。五、一个完整任务至少需要四个东西未来给Agent派任务可能越来越像写一个小型工程Spec。不一定很长但至少应该包含四部分。第一部分Goal到底要解决什么问题例如不是“优化登录”。而是将登录接口P95响应时间从当前水平降低重点排查认证后缓存读取链路。第二部分Scope允许处理哪些范围例如认证服务。缓存层。相关测试。第三部分Constraints哪些东西不能改变例如不能修改对外API。不能改变数据库Schema。不能删除现有兼容逻辑。第四部分Done Criteria什么状态算完成例如目标测试通过。性能问题可复现并验证改善。没有新增Regression。这四个东西一旦明确Agent执行空间会立刻缩小。六、Done Criteria可能比Prompt本身还重要很多AI任务为什么会越跑越久不是因为AI不会做。而是不知道什么时候应该停。比如“帮我把这个模块优化一下。”这句话几乎没有天然终点。代码可以继续优化。测试可以继续增加。结构可以继续整理。命名可以继续改善。所以Agent很容易不断发现“还有事情可以做。”但如果任务变成修复当前缓存刷新Bug相关测试全部通过并保证公开API行为不变。终点就非常明确。这就是Done Criteria它解决的是Agent时代一个非常核心的问题Termination Condition。什么时候结束如果没有Termination Condition一个能力越来越强的Agent反而更容易无限扩展工作。七、可以建立一个指标Task Clarity Score以后判断一个任务适不适合直接交给Agent可以建立一个简单指标Task Clarity Score任务清晰度。可以看五件事目标是否明确Scope是否明确限制是否明确成功标准是否明确出现异常时是否知道如何处理如果这五项里只有一两项清楚就不适合直接让Agent长时间自主运行。如果五项大部分都清楚这个任务才真正适合Deep Execution。也就是说AI能力不是决定Agent能不能长时间跑的唯一变量。任务本身的清晰度同样重要。八、为什么大型Repository更需要清晰任务小项目里即使目标模糊AI可探索的范围也有限。十几个文件。几个模块。很快就能看完。但大型Repository不一样。可能包含几十个服务。几百个模块。历史兼容逻辑。多个测试体系。大量配置。如果你只告诉AI“检查一下这里的问题。”搜索空间可能巨大。Agent必须自己决定看哪里。忽略哪里。哪些问题相关。哪些问题值得修改。任务定义每模糊一层搜索空间就扩大一层。最终大量计算并不是花在解决问题。而是花在判断你到底想让它解决什么问题。九、任务定义清楚以后AI最大的变化是“搜索空间缩小”这其实是Task Specification真正的价值。很多人以为写清任务是为了让AI“听话一点。”更深层的作用是Search Space Reduction缩小搜索空间。例如“检查支付系统有没有问题。”搜索空间非常大。但如果变成只排查支付回调在并发重试条件下为什么偶尔重复创建订单不改支付协议层不处理其他告警。AI一开始就可以排除大量无关方向。于是Search更少。Context更干净。Hypothesis更集中。Tool Calls更有效。Retry更少。最终真正节省的是整个任务的计算成本。十、这也是为什么AI越强任务拆分反而越重要很多人认为模型足够强以后应该可以直接把一个巨大的任务整个扔进去。理论上当然可以。但工程上未必划算。例如“把整个用户系统重构一下。”这可能包含认证。权限。Profile。缓存。数据库。API。测试。迁移。如果一次全部交给Agent任务状态会快速膨胀。更合理的方式可能是拆成认证边界确认。权限模型整理。缓存层重构。API兼容验证。测试补全。每一个阶段都有独立的Done Criteria。这叫Bounded Task有边界的任务。未来AI执行能力越强真正成熟的开发者越可能追求让AI长期执行小而清晰的目标而不是长期执行巨大而模糊的目标。十一、真正好的任务描述不需要写成几千字这又是另一个误区。任务清晰不等于Prompt很长。一个很长的Prompt也可能非常混乱。真正重要的是Information Structure信息结构。比如下面这种结构目标修复购物车并发更新导致数量覆盖的问题。范围Cart Service及相关测试。不要做不改数据库Schema不重构无关模块。完成标准并发测试稳定通过现有接口行为保持不变。实际上只有几句话。但对于Agent来说它比一大段“你认真分析一下整个项目看看为什么这里有问题尽量修好并确保代码质量……”价值高得多。因为前一种提供的是决策边界。后一种提供的主要是语气。十二、未来开发者可能越来越像“任务设计师”以前开发者主要负责写代码。以后AI承担越来越多执行以后人的工作可能逐渐向前移动。从Implementation移动到Specification。也就是定义问题。划定边界。建立约束。定义验收。决定优先级。然后AI负责执行。这并不是说代码能力不重要。恰恰相反。只有真正理解系统的人才能写出高质量Task Specification。因为你必须知道什么可以改。什么不能改。风险在哪里。什么才算真正完成。所以未来高级开发者的价值可能越来越体现在把模糊业务问题转换成AI能够稳定执行的工程任务。十三、这会进一步改变团队协作方式以前一个任务可能是产品经理描述需求。开发者理解。开发者自己实现。以后可能变成产品需求。开发者转换成Agent-ready Task。Agent执行。开发者验证。这中间会出现一个新的能力层AI-ready Specification也就是专门为Agent执行准备的任务定义。谁能够把复杂问题稳定转换成这种Specification谁就能让AI承担更多真正有价值的工作。所以未来团队之间的差距可能不仅是谁用了更强模型。而是谁拥有更成熟的任务定义体系。十四、任务交代不清其实也是一种计算浪费从资源角度看模糊任务非常贵。因为AI必须自己承担目标猜测。Scope探索。优先级判断。边界判断。Done判断。每一次不确定性都会增加Search。Reasoning。Tool Calls。Retry。Context。最终你可能觉得“这个Agent怎么这么吃资源”但问题可能并不完全在模型。而在Specification Debt任务定义债务。你前面少花了5分钟把任务说清楚后面AI可能多花30分钟探索。这就是典型的把人的定义成本转化成了AI的计算成本。十五、一个很实用的五问法以后准备把一个任务长期交给Codex之前可以先问自己五个问题。第一它最终要交付什么第二允许改哪里第三明确不能改什么第四怎么判断已经完成第五如果过程中发现其他问题要不要处理这五个问题如果都能回答这个任务通常已经比较适合Agent。如果连你自己都回答不了那就不应该期待AI在执行几十分钟以后自动猜对。十六、什么时候应该让AI自己探索当然不是所有东西都必须提前定义。探索型任务本身就是合理的。比如找出这个性能问题最可能的Root Cause。这时候允许Agent搜索。但即使是探索任务也应该有边界。例如允许探索哪些模块。需要输出什么Evidence。什么时候停止探索。最多保留几个Hypothesis。也就是说探索可以开放任务不能无限开放。否则“分析问题”很容易变成无限阅读Repository。十七、为什么这件事会影响Plus和Pro的判断这也是很多用户容易忽略的地方。如果一个人的AI工作流里任务经常很模糊。Scope不断扩大。Retry很多。AI经常跑偏以后重来。那他首先遇到的可能不是真实容量不足。而是Specification效率太低。这种情况下即使升级到更高容量也只是让AI能够跑更久的错误任务。所以应该先优化Goal。Scope。Constraints。Done Criteria。十八、什么时候Plus其实已经够用如果你的日常任务主要是明确Bug。中型Feature。代码Review。测试补全。小范围重构。并且每个任务都能够提前定义清楚目标。边界。Done Criteria。那么Plus通常已经可以覆盖大量开发工作。因为清晰任务会明显减少无效探索。Scope Drift。重复Retry。错误修改。同样容量下真正完成的有效任务会更多。十九、什么时候Pro才真正开始匹配如果你已经有成熟的Task Specification流程任务边界清楚。Done Criteria稳定。低价值探索减少。Agent跑偏能够及时发现。大任务也能拆成Bounded Tasks。但每天依然存在大量高复杂度。长执行链。高价值。必须持续运行的Agent任务。而这些任务本身的有效执行率已经很高仍然频繁受到容量限制这才说明你的问题正在从Workflow Problem变成Capacity Problem这时候Pro才真正开始匹配你的实际负载。最后AI越来越强以后一个很容易产生的误判是以后我们会越来越不需要把任务说清楚。实际上可能正好相反。当AI只能回答一句话时理解偏一点影响很小。当AI可以自主工作几十分钟、修改多个文件、运行工具、调用Subagent以后任务定义里一个很小的模糊点都可能经过执行链被不断放大。所以未来真正成熟的AI开发并不是“我只说一句剩下全部让AI猜。”而是“我把目标和边界定义到足够清楚然后尽可能把执行交给AI。”AI越强人越应该少做重复执行。但与此同时人也必须越来越擅长定义目标。划定Scope。设置约束。定义Done。因为Agent时代真正昂贵的可能不再是“没人干活。”而是一个非常能干的AI花了很长时间把错误的事情做得非常漂亮。持续更新Codex、大模型开发相关技术内容。长期使用各类代码大模型整理了稳定的Plus/Pro会员订阅渠道有需要可自取