你读过Cursor的指南，看过Claude Code的演示，在脑子里算过经济账，决定了：是时候了。你给团队下达命令——下个迭代试一试。两周后，你查看数字，发现lead time不是缩短了，而是增长了。奇怪的故障纷纷飞进缺陷跟踪器。两位最好的开发者走路时一脸「我早就说过了」的表情。在回顾会上听到的是客气的「我们需要更多时间来评估效果」。其实这就是说「把这玩意儿撤了」。
Claude Code指南和内容频道，我们发布资讯（当他们削减限额十倍时）以及我们通过Claude为项目实现的工具，频道：https://t.me/claudedevolper
听起来很熟悉吧？这是在工程团队中通过行政手段推行AI的典型场景。问题不在工具，不在模型，也不在那些持怀疑态度的人。问题在于推送模式（强制）的推行对高级开发者系统性地不起作用——你的团队越强大，它就越不起作用。
本指南讲的是拉动模式（吸引、参与）。需要建立什么，让资深开发者自己选择与代理合作，三个月后成为布道者。这不是关于励志演讲，也不是关于按AI代码占比发奖金。这是关于工程解决方案：工作流、基础设施和部署阶段，要能通过资深开发者的筛选。
为什么强制方法会失败
诱惑是可以理解的。这个话题很热，董事会在问问题，团队里有一对眼睛闪闪发光的初级开发者，他们的论点是"生产力提高了三倍"。逻辑上的下一步——标准化。给所有人安装工具，引入指标，在季度报告中汇报。
接下来发生的事没人预料到。
代码审查卡住了。PR的数量增加了，审查人的工作负荷飙升。生成的代码看起来可信，但"更沉重"，读起来比手写代码慢：多层结构、违反约定、在意想不到的地方出现微妙的副作用。资深开发者花在审查上的时间比初级开发者在编写上节省的还多。净账户是负数。
发布周期变长了。代码库中方法的熵增加了——这里一种风格，那里另一种，再那里第三种，全在一个仓库里。架构决策是在没有全局视野的情况下做出的，因为每个人都有自己的代理和自己的上下文。两三个迭代后，积累了技术债，没人明确投入过它——它只是出现了。同时，事故数量也在增加：一些bug通过重负荷审查时漏掉了。
最优秀的人暗中破坏。不是公开的——只是继续手工编写代码，在会议上说"我试过了，不适合我"，在聊天中对初级开发者的热情做出怀疑的反应。这不是固执，也不是卢德主义。底层是四种具体的恐惧，每一种都是理性的防御反应：
- 与职业身份的冲突。资深开发者是一个其价值建立在所做决策质量基础上的人。当你向他提议"描述任务——接受生成的代码"这种模式时，你给了他一个技术写手-审查员的角色，而把作者的角色给了模型。无论幻灯片上包装得多漂亮，这都不是职位上升。这是职位下降。
- 害怕去技能化。不是想象的，是真实的。如果三年来主要通过生成来写代码，掌握架构在脑海中、感受代码异味、区分正确解决方案和看起来正确的解决方案的技能会怎样？
- 失去自主权。决策是自上而下强制的，工具被强加，"AI代码百分比"指标悬在头顶。这与强大的工程师历来工作的模式完全相反——也正是他们的专业知识由此而生的。
- 工作安全威胁。不是"我会被模型替代"——那是初级开发者的恐惧。资深的更微妙："如果我的价值归结为审查生成的代码，我就是可以互换的"。资深开发者站得越稳，感受得就越敏锐。
推送模式试图忽略这四点，通过KPI强行推进。拉动模式——将它们作为设计需求来应对。这就是全部区别。
资深开发者实际上想从AI那里得到什么
如果把前一部分的四种恐惧翻转180度，就会得到一个需求清单。不是对工具的需求——是对工作模式的需求。这不是可以通过订阅购买的"功能"。这是工作流的属性，要么有，要么没有。
资深开发者想保持作为解决方案作者的身份。不是审查员，不是模型的操作员，不是生成代码的接收者。是作者。这意味着——代理在做出架构决策之前就参与进来，帮助做出决策，而不是实现已经做出的决策。矛盾的是，正是代理的早期参与——在研究和头脑风暴阶段——消除了"我沦为审查员"的恐惧，因为在这种情况下，作者的角色仍然属于人。在研究中，代理是对话伙伴。在实现中是执行者。不是反过来。
资深开发者希望自己的专业知识得到强化，而不是萎缩。这是一个微妙的地方。任何强大的工程师都知道：技能在需要思考的地方增长，在不思考的地方萎缩。如果代理承担"思考"，技能就会流失。如果代理承担"搜索、验证、综合例程"，而思考留给人类——技能增长会比没有代理时更快。工作流必须明确分离这两种模式。不是"代理自己完成所有工作，我只按了确定"，而是"我通过自己的思维过程指导代理，得到的输出是我的想法转化为代码"。
资深开发者希望对流程有个人控制权。不是"试试周一前的新工具"，而是"这是个机会，按你自己的节奏来"。可选性在这里不是礼貌——而是设计需求。如果代理被强制使用，它的任何缺陷都进入"我早就说过了"的积累。如果是被选择的——同样的缺陷被看作自己决策的成本，而不是系统失败。
资深开发者希望自己的角色变得不易替代，而不是更易替代。这是最违反直觉的部分。推送模式隐含地传达："你们现在都是AI的操作员，你们之间的差异模糊了"。拉动模式应该传达相反的信息："实施后你们变得更有价值了，因为与代理高效合作是一项独立的技能，你们拥有它，初级开发者没有"。矛盾的是，现实恰好是这样的：强大的工程师用代理的效率比弱的工程师高一个数量级。强者提出正确的问题，看到输出中的缺陷，守住范围边界，不让代理把自己带进死胡同。弱者——生成垃圾的速度比以前更快。
这四点不是营销。这是本文其余部分的需求规格。接下来我会分析原理、工作流程、基础设施和实施阶段——在每个部分我都会明确展示这四点中的哪一点由哪种机制来解决。如果在你未来的实施中其中一点没有得到解决——那它就无法通过资深工程师的审查，无论其余部分包装得多么漂亮。
核心原则：代理处于从属的主动位置
我不断重复这个公式，每次都能看到人们眼中的疑惑："也就是说怎么做？主动——那不就是自己做？"不是。这——就是关键所在。
大多数关于代理开发的演示和博客文章都是建立在相反的模型上的：给代理一个任务，它自己分解它，自己实现它，自己打开PR。人类在输入端制定，在输出端接受。我们称之为自主位置。它在推特上看起来很好，在真实的代码库上效果很差，并且绝对无法通过资深工程师的审查。因为它需要信任，而资深工程师没有——并且也不知道从哪里获得。
从属的主动——这是另一种模式。我将分别沿两个轴线展开。
从属——意味着代理不作任何决定。一个都不作。不选择架构，不批准范围，不决定是否需要重构相邻的模块，不在明确命令下打开PR。所有决定都由人类做出。这给了资深工程师那种在自主模式中所没有的个人控制。更重要的是，它保留了他的作者身份——代码中的每个决定实际上都是他的，而不是模型的。
主动——意味着代理不等待被要求。它自己在代码库中运行，自己检查假设，自己提出矛盾，自己提出替代方案，自己提醒你遗漏的内容。不是"等待提示"——而是"我看到这里出现了风险，我们该怎么做？"。
在实际生活中——这是高级开发人员与能力强的初级实习生一起工作的模式，后者具有广博的知识、闪电般的速度和零责任。实习生很有主动性——提出问题，提供选项，比要求的挖得更深。但决定由主要开发人员做出。实习生不会在没有批准和审查的情况下推送到main，不会"顺便"重写相邻的模块，不会认为他更了解。他增强了主要开发人员的思维过程，而不是取代它。
这个类比不仅用于理解。它作为工作流程设计的基础，而不是凭空发明其他宇宙中的方法。
这里消除了脱技能化的主要恐惧。当代理处于从属位置时，思考仍然由人类完成。代理承担代码库搜索、假设检验、选项综合——即不会增长技能的例行工作。而思考——在哪里设置范围的边界，什么权衡是可以接受的，什么抽象是正确的——仍然由工程师负责。经过半年的这种工作模式，技能不会萎缩，反而增长更快，因为工程师在相同的时间内处理更多任务，每项任务都要求他进行思考，而不是搜索的麻烦。
从从属的主动性引出了第二个属性，这个属性经常被忽视：代理应该尽早被纳入流程。在写第一行代码之前。在你自己知道确切答案之前。在"我大概理解需要做什么，但对细节不确定"的阶段。正是在这里代理提供最大价值——因为它比你更快地在代码库中运行，同时保持更多的上下文，并且不会对第二十个澄清问题感到疲倦。
如果你晚期引入代理——在"为我写一个做X的函数"的阶段——你是在把它当生成器用。这正是引起资深工程师反感的模式。因为在这个模式中，代理确实在取代作者，而不是增强。
从属的主动位置——这不是一个设置。这是由三样东西构成的结构：工作流程、指示（上下文层）和开发人员的习惯。工作流程设定节奏——代理在哪里进入、在哪里停止。指示设定边界——它可以做什么、不应该做什么。习惯设定质量——你与它交流的能力如何。接下来我们逐个分析这三项。
工作流程
从属的主动位置本身——是个概念。没有流程，它无法实现。工作流程正是概念转化为日常实践的地方，它也是作为团队领导的你需要创建或采用并适配的主要工件。
流程的想法很简单：与其给出声明性命令（"写一个函数"、"找一个bug"、"生成测试"），代理和工程师在一个交互循环中移动——研究任务、检验假设、讨论选项、确定规范和接收标准、分解、分段实现并能够在不破坏流程的情况下进行干预、进行带有中间审查的检查点、进行测试覆盖，最后在PR前进行最终审查。
这不仅仅是漂亮的顺序。这是三个阶段，每个阶段中代理的角色不同。
构思。最重要的阶段。这里代理是交谈者，不是执行者。以"我们在做特性X，这是用户故事，这是接收标准"的形式接收意图。接下来——问答模式。代理研究代码库，提出矛盾，提出澄清问题，提供替代方案。输出——设计文档具有固定结构：目标、范围、非目标、架构原则、契约、风险、决策日志。
这里消除了"我被简化为审查"的恐惧。设计文档中所有决定的作者是人类。代理是结构化他思维的工具，而不是替代。
规划。当设计被固定后，我们切换到"怎么做"。目标——将任务分解为冲刺，每个冲刺都有自己的范围、接收标准和爆炸半径评估。冲刺=原子工作单位，不会让代码处于非工作状态。在这个阶段，代理再次浏览代码，但焦点已不是"要构建什么"，而是"放在哪里以及会影响什么"。通常在这个阶段，会出现头脑风暴中遗漏的细节。
这里资深工程师仍然是实现的架构师。不自己写计划——但批准每一个转折。这正是自主权，通过专业知识和决策权来保持自我价值。
工作循环。循环plan → implement → review → fix → review → commit，按冲刺重复。每个冲刺内——单独的会话。冲刺之间——提交是强制性的。下面是示意图。
关于代码审查。代码审查必须在单独的会话中进行。不能在实现的那个会话中进行。在同一个会话中，模型对自己的结果有偏见——说实话，就像我们一样。在单独的会话中，它能发现有偏见的会话中没有发现的问题。我个人除了目视审查外，还会并行运行两个不同模型的会话：比如 Claude 和 Codex。它们发现的问题不同，这客观上提高了质量。
这里顺便说一句，一个工程师在代理开发时代的主要新技能逐渐清晰起来——精确性、思维清晰性、系统性和耐心。"人工审查 → 代理修复"的循环工作效率完全取决于你解释问题时的清晰程度。如果你东扯西扯，代理就会陷入复杂的细节。如果你粗暴且离题回答，你会得到一个临时方案。一切就像和真人打交道，只是你无法解雇这个人。
技能——没有它们就什么都无法工作
所述工作流程在单纯的模型上是不可能的。每个阶段都要求代理表现出特定的行为，而任何前沿模型本身都不会表现出这种行为。在普通指令下，它会写代码——但我们需要它先提出问题、然后探索代码库、然后将解决方案保存到文件、最后才写代码。
这通过技能来解决——包含上下文指令的单独文件，这些文件在代理需要进入特定模式时加载。从技术上讲，这些是修改过的系统提示，但在效果上就像角色切换。在技能下，模型能做出奇迹，这些在普通指令下通常做不到。
最小工作集是三个技能：
- brainstorm——将代理转换为对话模式。接收意图、进行研究、提出挑战、记录解决方案，输出——设计文档。
- planner——将其转换为实施架构师模式。接收设计文档、根据实际代码检查、分解为冲刺、输出——开发计划。
- code‑review——将其转换为审查者模式。在新会话中接收冲刺实施结果、输出报告。
我将这些技能发布为开源：github.com/pridees/skillforce。它们经过调整可相互配合工作、在 Claude Code、Codex、Gemini、Open Code 和其他几个代理上测试过、在 Anthropic、OpenAI、Kimi 和 GLM 的模型上测试过。我不能保证它在你的环境中会完全相同地工作——模型不同、代理不同、代码库不同——但作为起点绝对够用。然后你可以根据自己的具体需求进行调整。
安装（可能需要安装 nodejs）：
npx skills add pridees/skillforceОбъяснить с
作为团队领导，你不应该让每个高级开发者从零开始构建这个。你的关键贡献之一是集中化准备技能和上下文层，采用便于连接到仓库的格式。这消除了对高级开发者的巨大"入门成本"，否则他们永远不会独立进行配置。同时，它消除了我们在推送场景中看到的团队方法的不一致。
应该在仓库中出现的内容
团队领导不需要了解每个提示词——但必须知道每个阶段的输出应该是什么。这是你检查工作流程是否真的工作而不仅仅是模拟的主要工具。
Design document（brainstorm 后）。结构：Understanding Summary、Non‑Goals、Assumptions、Design Principles、Data Model / Contract、Runtime Behavior、Testing Strategy、Decision Log、Acceptance Criteria。
Development plan（规划后）。结构：Overview、Prerequisites、Sprint 1...N（每个都有自己的目标、任务、验收标准、验证）、Testing Strategy、Risks & Rollback。
你可以将它们存储在仓库中，我通常在发布后两周删除。如果代码中突然发现了 bug，提交哈希、规范和计划有助于快速恢复调试的上下文。
基础设施准备
技能只是其中的一半。另一半是存储在仓库中并在代理每次工作时加载的内容。这是一切运行的基础框架，以及决定代理如何理解你的项目的上下文层。
Harness
Harness 是"智能"（模型）和"执行"（你的代码和测试）之间的一层。本质上，这就是日常意义上的"代理"——Claude Code、Codex CLI、Cursor agent mode、Open Code。它们的任务不是"代替开发者写代码"，而是闭合受管理的 SWE 循环：获取任务、探索代码库、规划、做出更改、同步指令、调用 tool 和 MCP。
主要要求是自我检查的能力。代理循环内应该有批评和自检阶段：运行编译器、linter、测试。或者通过钩子手动配置这个的能力。没有这个，harness 不是 SWE 工具，只是一个漂亮的自动补全聊天。
选择不多。主流选项是 Claude Code 和 Codex CLI，两者都可以切换到第三方提供商的模型（如果你公司在政治上可以接受的话）。如果不能接受——我个人的建议是 Pi，一个极其可扩展的工具，允许你添加所有需要的东西。对于模型——选择最好的可用模型；如果无法使用前沿模型，开源权重中目前 GLM/Kimi/MiniMax 级别的模型表现相当不错。
作为团队领导，你为整个团队选择一次 harness 并将其纳入标准。异构性在这里是大忌：不同的 harness 读取不同的指令格式，为一个调整的上下文层不适用于另一个。
上下文层
这是你的基础设施的心脏。这里存放着所有的协议、约定、指南、技能和模式，它们使你的代码库与其他任何代码库都不同。你在前两个月内传给新开发者的东西，需要通过文件传给代理。
我这样构建这一层：
/ ├── .agents/ │ ├── rules/ │ │ ├── coding-guidelines.md │ │ └── conventions.md │ ├── skills/ │ │ ├── brainstorm/SKILL.md │ │ └── code-review/SKILL.md │ └── AGENTS.md Объяснить с
接下来——针对特定 harness 的符号链接：.agents/AGENTS.md → .claude/CLAUDE.md 或 .agents/AGENTS.md → .codex/AGENTS.md。OSS 代理开箱即用地理解 .agents 或允许在配置中指定名称。
AGENTS.md——主要代理指令。基本结构：项目定义、开发规则（带有指向 rules/ 的链接）、仓库结构、规范指南、提交约定、red flags（我们绝不做的事情）、构建和测试命令、文档链接。最小通用模板，可以用来开始，我已经发布为单独的 gist——gist.github.com/pridees/82eef0e1710196188492695baef20ee6。拿去，根据你的堆栈进行调整。
实际上，`AGENTS.md` 不需要从头手工填写。有更简单的办法：让代理`做一份仓库及其规则的内省，并更新@.agents/AGENTS.md，保持结构不变`。然后进行审阅和编辑。一次性为整个团队完成。
核心原则："模型能自己搞定"
这是一件通常只有经过几次迭代后才能理解的反直觉之事。
配置时很容易陷入想把所有情况都描写出来的诱惑——所有规则、所有约定、所有例外。别这样做。原因如下：
- 膨胀的 `AGENTS.md` 占用上下文窗口的空间。每个指令令牌就是从任务里挪走的令牌。规则越多，代理解决问题的效果越差。
- 指令与真实代码相互矛盾。现实总是比书面描述更丰富。代理看到代码就会可预见地按所见方式编写。但你会因为它"没有遵循规则"而恼火。
- 命令式规则很脆弱。"控制器这样写"——如果控制器不是这样呢？"不要用 X"——如果在某个地方就是需要呢？每个例外都需要更新指令。
一个更强大的方法是：在与代理工作的过程中逐步澄清细节，用你的代码作为示例来源。如果你有设计良好的模块或成功实现的功能——只需描述场景并引用这些文件。"在处理域层时，看 `src/domain/order` 作为示范"。与其写一页指令，不如写一行加上你自己代码库里的真实例子。
规则也是一样：不要为 `rules/` 里的每个文件都写 `You MUST read`。关于 REST 控制器的指令在处理域层时是不需要的，反之亦然。只需描述该指令何时适用——模型自己就能搞定。
重复出现的模式和提示词，那些在你或开发人员的工作中不断出现的东西，把它们提炼成独立的技能。上下文层是活的，它与团队一起成长。
作为团队负责人，你的任务不是一次性写出完美的 AGENTS.md，而是创造它演进的过程。由某一个人（你或指定的维护者）保持上下文层处于最新状态，接收来自团队的规则和技能 PR，追踪开始重复出现的东西。这不是一次性活动，而是仓库中的新仪式——就像 CODEOWNERS，只不过是为了上下文。
在团队中推行的方法
Harness 已选定，上下文层已构建，技能已在仓库中。接下来是最难的部分。将基础设施转化为实践，而不会滑回我们刚刚分析过的推送模型。
我将部署分为三个阶段。每个阶段都有自己的逻辑、指标和出问题的方式。
第 1 阶段。早期采用者（early adopters）
在团队中找 1-2 个自己想和这个一起工作的人。别劝说，别"给个机会"。他们想这样做，意味着已经在自己那边试过了，对幼稚的方法感到失望，准备好投入精力去做一个正常的工作流。理想的候选人是有成熟怀疑精神的资深工程师，而不是眼睛闪闪发光的新手。
他们在这个阶段的任务不是"把团队转向 AI"。他们的任务是在真实任务上体验工作流，并产生可见的产物：设计文档、开发计划、干净的 PR，审阅快速且不需要重写。几个上线的功能。这将是你的证明。
不要设置截止日期。不要引入指标。不要向董事会报告这个阶段。任何公开性都会破坏它——志愿者会开始为报告而工作，而不是为质量而工作。
第 2 阶段。扩展
当这些人有了可信的结果时，你就打开邀请。不是"现在每个人都试试"，而是"看看我们试过的东西——现在所有感兴趣的人都可以用"。技能和上下文层在仓库里，文档也有，也许还有一个内部会议，同事们展示他们的实际工作方式。没有压力。
然后你就观察。有人立即加入，有人一个月后加入，有人三个月后加入。这是正常的。拉取模型不是说所有人都在一天内加入。拉取是指他们自己来。
完全不要理会怀疑者。他们中的一些人会在看到同事的结果后加入。一些人会在自己撞上工作流能解决的那面墙后加入。一些人永远不会加入。你也必须能够接受最后一个场景：不是每个开发人员都应该与代理工作，试图把工作流强加给所有人就是那个旧的推送模型穿上了新外衣。
第 3 阶段。标准化
当 70-80% 的团队稳定地使用工作流时——正式化它。不要更早。`AGENTS.md` 在仓库里是必需的，harness 是标准化的，技能是集中的和维护的。在这个阶段——是的，你可以要求。但要求的不是"使用 AI"，而是"遵守仓库约定"。谁想手工写——可以，关键是约定。
永远不要引入 KPI"AI 生成代码的百分比"。这是我见过的所有推送部署中最流行且最具破坏性的指标。它优化了正好不应该优化的东西，鼓励了工作流本来要保护我们免受的行为。
关于指标：
- 从接手任务到 PR 合并的交付周期。不应该增长。如果你一开始就看到速度的提升——团队过度依赖了 AI，这也不好。这个指标的改进应该与下面提到的指标一起考虑。
- 每个审阅者的审阅吞吐量——一个审阅者每周审阅多少 PR，花多少时间。这是你对隐藏推送模型回归的金丝雀。如果团队中有人开始以"做了——发送了"的模式生成代码（正是我们要摆脱的行为），审阅者的负担会在其他指标发现之前飙升。
- PR 返工率——首次审阅后需要进行重大更改的 PR 比例（不是表面修饰，不是评论，而是逻辑重写）。不应该增长。如果增长了——意味着 brainstorm/planning 被跳过了，工作流退化成了"按需生成"。
- 平均恢复时间——从事故到恢复所花的时间。间接显示了团队对其生产的代码的理解程度。这里是 AI 实施最狡猾的风险所在：代码写得更快，但如果作者没完全理解它（因为委托了太多），在事故时就会暴露出来。MTTR 上升 = 去技能化已经实现，需要重新审视工作流，以增加人类在 brainstorm/planning 阶段的参与。
- 每一两个冲刺进行一次简单的团队调查。一个问题："工作流在多大程度上帮助或阻碍工作？"NPS 格式。数字不重要——重要的是趋势。
不要测量的东西：
- AI生成代码的百分比。毫无意义的指标，三下五除二就能优化，奖励有害做法。
- 生成速度。衡量的是工具，不是生产力。
- PR中的代码行数。代理倾向于堆砌解决方案，这个指标正好鼓励这么干。
有害的反模式
一个短检查清单，列出会在一步里砸碎拉动模式的东西：
- 部署截止期。「到季度末所有人都在用」= 推送。
- KPI「AI代码百分比」。已经说过了。
- 公开对比。「看，Вася因为用了代理快了两倍」——保证Вася会被孤立，其他人开始有意破坏。
- 禁止手工写代码。如果任务很小或显而易见——工作流就过度了。禁止 = 无谓的挫折。
- 强迫早期采用者去教育其他人。他们的工作是产出成果，不是当传道士。传道必须是有机的，否则会惹人反感。
- 从外部接受指标。如果部署标准来自更高层级——你手里不是团队，是车间。保护自治。
作为团队主管，你的贡献不在部署速度。3到6个月后，你的团队应该长出成熟的工程实践，而不是一群焦头烂额被动抵抗的人。
最后
部署后几个月，你往回看，意识到一个奇怪的事。最有价值的成果不是完成的任务数增加，不是lead time缩短，也不是资深工程师满意。最有价值的成果是团队思维方式的改变。
要让处于从属但主动位置的代理产出我们需要的东西——我们必须学会比以前更精准地表述意图。更深入思考我们在构建什么，不丢掉对「怎么做」的视线。在写第一行代码前分解任务。看清范围并用言语固定。在代码审查中表述论点，避免下一轮留下临时补丁。耐心走完整个周期，而不是「现在我自己快速完成」。
这些技能——精准性、思维清晰、系统性和耐心——才是最大的收获。它们不是工具给的礼物。它们之所以成长，是因为工作流每天都在要求。人工智能已经足够好来解决日常任务，但它鲜明地照亮了我们经常掩盖的东西——我们如何向彼此传达思想和意图。
这就是为什么推送模式永远给不了这个结果，无论引入多少KPI。强制压制剥夺了工程师的创作权，用生成代替了思维。参与——迫使思维比没有代理时工作得更努力。差别不在速度。差别在于一年后团队会变成什么。
作为技术主管，你的角色是创造一个使这成为可能的空间。技能、上下文层、部署阶段、保护团队的自治不受外部指标影响。之后资深工程师会自己搞定。他们就是因为这个才叫资深工程师。
Claude Code指南和内容频道，我们发布资讯（当限额被砍掉10倍时）和我们通过Claude为项目实现的工具，频道：https://t.me/claudedevolper
