1. AI编码代理的失控时刻为什么没人敢放手让它写代码如果你这段时间用过Cursor、Windsurf这类AI编程工具八成已经体会过那种又爽又怕的感觉。爽的是一个前端页面、一个后台接口、一段脚本敲几行提示词就出来了怕的是代码一旦过了几百行、涉及多个模块AI就开始自由发挥——擅自改了不该动的公共函数、凭空造了几个你没见过的配置项、修了一个Bug却带出三个新Bug。这种状态我一般叫它AI失控前兆。我过去一年里在好几个中大型项目里做过AI编程工具的深度测试坦白讲纯粹的对话式编码在单点任务上确实能打但在需要严格遵循既定架构和业务规则的场景里可靠性是远远不够的。问题不在于模型笨而在于我们交付给模型的上下文是零散的、模糊的。你跟AI说把登录模块重构一下它理解的重构和你脑子里的重构大概率不是一回事。没有一套机器可读的规范来约束它的行为边界AI编码代理就像一个没有轨道的滑板——方向对了能滑很远方向偏了就只能翻车。所以当我第一次看到Trellis这个开源框架时给AI编码代理装上辅助轮这个定位一下子就击中了我。它在GitHub上的热度不算低社区讨论也不少但很多人还停留在听过名字、不知道具体能干嘛的状态。这篇文章就把我实际使用和改造Trellis的经验梳理一遍重点讲清楚它解决的到底是什么问题、tuft规范文件怎么落地、以及哪些项目真的适合用它。如果你正在被AI写代码太野困扰这篇文章值得看完。1.1 失控的三种典型表现先说我在实践中总结出的AI编码代理失控三连这是判断你需不需要Trellis的直接信号。第一种是范围蔓延。你让它加一个导出Excel的功能它顺手帮你把整个列表页的筛选器也重写了。你问它为什么它说觉得这样更统一。听起来很合理是吧但在真实项目里这种主动是灾难——它改动的代码没有经过设计评审很可能破坏了你原有接口的兼容性而你还得花大把时间审查它的附加创作。第二种是伪完成。AI告诉你接口写好了测试也跑过了但实际上它只是调通了Happy Path——异常分支根本没处理鉴权逻辑被当成多余代码删掉了错误信息给得莫名其妙。我在测试中就遇到过AI自信满满地向我展示联调成功的截图结果仔细一看它自己在一个临时Mock里把返回结果写死了。第三种是架构漂移。项目里明明约定好了分层规范比如Controller层只管参数校验、Service层管业务逻辑但AI写出来的代码经常把业务逻辑直接塞进Controller理由是这样写更短。单次看问题不大积累下来就是整个项目结构崩塌后期维护成本直线上升。这三类问题的共同根源是我们从来没有把边界和验收标准以结构化的方式告诉AI。对话里的三言两语管不了模型几百层的注意力分配一旦上下文稍微长一点它就记不住你最初的约束了。1.2 根本原因不是模型能力而是上下文约束方式很多人觉得AI失控是模型能力不够等GPT-5出来就好了。我在实践里越来越不认同这个观点。模型能力固然是基础但更关键的瓶颈在约束的表达方式上。想想我们人类是怎么约束一个开发者的我们给他PRD、给他接口文档、给他代码规范、给他Code Review的Checklist。这些内容不是口语而是结构化的、可执行的规范。但我们现在怎么约束AI的靠对话里的一句注意代码规范哦或者塞给它一个几百页的文档让它自己领悟。模型确实能领悟一些但它领悟出来的规则和你脑子里的规则不一定一致而且一段对话中它可能随时改变主意。Trellis的核心思想恰恰是把约束过程从提示词的偶然性变成规范文件的确定性。它不再依赖AI在生成过程中自觉遵守什么而是通过一套显式的、分步骤的流程让AI在动手写代码之前先把你打算怎么干交底出来由人来审查。这一步就拦掉了大部分的范围蔓延和架构漂移。另外很多团队忽略了一个基础事实上下文长度不是无限的。就算模型支持200K的上下文塞进去的有效信息过多了照样会稀释注意力。Trellis通过规范化文件把关键约束组织成精炼的、按需加载的形式让编码代理在每一个工作阶段只看到当下最需要的规范这比一次性把所有规则都丢过去要可靠得多。这个设计思路我觉得才是它真正值钱的地方。1.3 现有AI编程工具的补救思路为何远远不够有人会说Cursor / Copilot里面也能指定.cursorrules或者AGENTS.md之类的文件啊功能上不也是约束AI吗我实测下来这类方式有个天然的短板——它们是建议不是流程。Trellis这种辅助轮框架的核心价值在于它保证你定义的规范先于代码被看到。它把AI编码这事拆解成规范定义 → 规划评审 → 测试先行 → 编码落盘 → 验证兜底这套流程把AI代理的每一次操作都置于规范和人的双重检视之下——这是单纯提示词约束完全做不到的。从实际体验上看用Trellis跑过一两个项目之后我最大的感受就是沟通成本变高了返工成本却大幅降下来了。你需要在初期花时间把规范写清楚这确实比直接让AI写麻烦。但换来的是一旦写完AI的执行稳定性和结果可控性会好上几个量级。对于稍微有点规模的项目这笔账是划算的。下面我就具体聊聊Trellis到底是怎么做到这件事的。2. Trellis的解题思路把你觉得应该怎么干变成机器可读的规范Trellis的GitHub仓库里有一句话给我的印象非常深大意是每一个AI任务的成败取决于所提供规范的质量。这句话翻译成大白话就是AI干活垃圾先别急着骂模型先想想是不是你给它交代得就是个糊涂账。这其实是整个Trellis的哲学原点。它整个框架的设计都是围绕着如何把口头要求变成严格规范、如何让规范真正约束AI行为来展开的。2.1 核心哲学规划与执行解耦把主导权还给人类Trellis把一次完整的AI编码任务拆成了两个阶段规划阶段Planning和执行阶段Implementation。规划阶段AI要阅读你提供的所有上下文材料——GitHub Issue、RFC文档、现有代码结构、相关规范——然后产出一份结构化的实现规划。这份规划不是让你看看就算的它要过你的审批。你发现AI理解的方案有问题直接打回重写。你觉得范围蔓延了在规划阶段就能让它把多余的部分去掉。这一步争论最多、却也是价值最大的一步它把错误拦截在了写代码之前。执行阶段AI严格按你批准的规划落地代码并且要通过Trellis内置的TDD循环——先写测试再跑测试再写实现让测试变绿。整个过程受控且透明每一步都有迹可循。这套规划与执行解耦的设计本质上是把AI从决策者降级为执行者。在很多传统AI编程的用法里AI是一边思考一边写代码决策过程不可见等你反应过来它已经改了十个文件。Trellis逼着它先把决策拿出来给你看你点头之后再动手。这就是辅助轮最核心的机制不让AI在无人看管的状态下全速前进。2.2 tuft文件与TTT语言规范长什么样Trellis的规范文件有一个专门的名字叫tuft用后缀.tuft.md来标识。它使用一种专门设计的轻量级语言TTTTest-Tracked Tuft编写长得非常接近Markdown但带有YAML格式的元信息头以及明确的区块标记。这种设计有两个好处人类读起来直观机器解析起来也不费劲。一个标准的tuft文件大致长这样--- title: 添加用户登录会话管理 tracking: feature-auth-session status: accepted prd: https://example.com/prd/123 --- ## 背景 当前系统没有统一的登录会话管理模块用户在多个页面登录时会出现会话冲突。 ## 指路牌Guardrails 1. 不得修改现有用户表结构 2. 新增的会话存储必须使用Redis禁止引入新的存储中间件 3. 接口路径必须符合 /api/v1/session/* 的规范 ## 验收标准 - 用户登录成功后返回会话令牌有效期不超过30分钟 - 同一用户同时只允许一个有效会话 - 退出登录接口必须使会话令牌立即失效这段内容看起来没什么惊人之处但它把AI编码时最需要的三个东西全给出来了为什么做Background、不能做什么Guardrails、做成什么样算对Acceptance Criteria。这比你在对话框里说一百句注意安全都管用。TTT语言的几个关键概念我后面单独开一节详细讲这里只提一点tuft文件里的Guardrails被设计成机器可检查的规则比如禁止添加依赖项禁止修改某个目录下的文件接口路径必须匹配某个正则。Trellis在执行阶段会启动校验逻辑AI如果真的违反了这些规则会被明确告知并要求修正。这一点是纯文本提示词完全做不到的——文本只能期望模型遵守而Trellis是实体逻辑上的硬性检查。2.3 为什么规划先行能显著降低AI改变主意的概率我在实际使用中观察到一个特别明显的现象没有明确规划的AI编码中途改主意的概率极高。最开始说好这个接口返回JSON格式你聊了两个来回之后它可能已经偷偷改成了返回XML因为它觉得这样更好。Trellis的规划先行机制直接把这条路堵死了——规划报告批准之后执行阶段的所有decisions都有据可溯AI不是不能再改但每次偏离规划的动作都会被标记为异常需要人来介入确认。这就像在导航App里设定好目的地和偏好路线之后司机偶尔还是会主动偏离导航去抄近道只有乘客在副驾盯着才不敢乱来。Trellis就是那个盯着地图的副驾它允许AI在路线内自由选择加速、超车、变道但不允许它偏离到没有规划过的区域。3. tuft规范文件到底怎么写从零手写一个能跑的项目规范聊完理念进入实操环节。我知道大家最关心的还是这玩意儿到底怎么写、能不能立刻用起来。我直接用一个示例场景带大家走一遍大家拿自己的项目替换细节就能上手。3.1 最小可用的tuft文件结构先说最基础的结构。Trellis中的每个任务对应一个tuft文件文件可以放在项目的tufts/目录下。你可以按任务拆分成多个文件Trellis会自动识别。我从一个实际场景出发假设你的项目需要一个用户积分明细导出功能。最小可用的tuft文件如下--- title: 导出用户积分明细Excel tracking: feature-points-export status: draft prd: https://yourwiki.com/prd/points-export --- ## 背景 运营需要按时间范围导出用户积分变动明细用于对账和数据分析。目前系统只有积分总览页面没有明细导出能力。 ## 指路牌Guardrails 1. 导出数据必须从积分明细表 points_transaction 读取禁止使用临时拼接的假数据 2. Excel文件必须使用.xlsx格式禁止输出CSV 3. 导出接口需要鉴权只允许管理员角色调用 4. 文件生成后上传至OSS返回下载链接禁止直接将文件流返回给前端 5. 本次改动不涉及积分余额计算逻辑不得修改 points_balance 相关代码 ## 验收标准 - 提供导出接口请求参数包含 开始时间、结束时间、用户ID(可选) - 导出的Excel包含以下字段用户ID、用户昵称、变动类型、变动数值、变动前余额、变动后余额、变动时间、订单号 - 单次导出数据量超过5万条时自动拆分为多个文件每个文件不超过5万条 - 接口响应时间不超过30秒异步任务模式 - 附带有单元测试和至少一个测试数据样例这个文件其实已经涵盖了写好tuft的80%的关键点后边小节我拆开逐个解释每个字段的设计意图。3.2 关键字段拆解Title、Background、Guardrails、Acceptance CriteriaTitle标题和 Tracking任务标识title没什么好说的就是任务名。tracking字段建议花点心思它是后续Trellis追踪任务状态的标识。团队里如果有Issue管理系统最好直接关联Issue编号比如feature-points-export关联GitHub Issue #128这样从规范文件就能反查到需求来源。Background背景很多人写规范会略过背景我强烈建议不要省。AI对上下文的理解深度直接取决于背景铺垫是否充分。背景写得清楚AI在做技术选型时就会有方向——比如看到当前系统已有积分总览页面它会主动去复用已有的数据查询逻辑而不是新造一套。背景不是给AI看的花边文字而是它做一切决策的依据源。Guardrails指路牌硬性红线这是Trellis最核心、最强约束力的部分。我把Guardrails分成几类写的时候可以对号入座数据边界允许读哪些表、禁止碰哪些表、数据从哪里来。示例里第1、5条就是这种。技术边界允许用什么格式、什么中间件、什么库、什么存储。示例里第2、4条就是这种。行为边界哪些动作必须做、哪些动作禁止做。示例里第3条要求必须鉴权就是这种。代码结构边界允许改哪些文件、禁止改哪些目录。上节里Trellis示例中的不得修改用户表结构也是这种。写Guardrails的经验是宁可多写不要少写。你不可能预知AI会在哪个细节上放飞自我所以把你能想到的边界都摊开来说。一个没有Guardrails的tuft跟没有提示词的AI对话没什么区别都会偏。Acceptance Criteria验收标准验收标准是做成什么样算好的客观依据。写验收标准时有一个原则要可验证不要模糊。比如导出Excel包含用户昵称这是可验证的但导出性能要好就是不可验证的——好和不好没有标准。在实践里我会把验收标准写成带条件的可测试陈述比如示例中的接口响应时间不超过30秒异步任务模式这一条定义了数据量、超时时间、实现模式三个维度AI执行完可以自行核对人工审查也有据可依。3.3 为 Tuft 收集正确的上下文与支持文件Trellis不是让AI凭空理解你的项目推广规范化的跑法需要配合支持文件。说白了一个tuft文件更多像任务牌具体背景仍然需要嵌入相关资料让AI去看它该看的代码和文档。我在项目里会为每个tuft准备一个支持文件清单往往是以下四类之一相关代码路径明确告诉AI这个功能涉及src/modules/user/points/目录下的文件缩小它的搜索范围提升响应速度。接口文档如果项目里有OpenAPI/Swagger等接口定义把对应部分截取出来给AI当一个不允许偏离的接口契约。数据库Schema逻辑表结构、字段含义、索引情况防止AI生成低效或错误的SQL。历史故障记录如果你这个模块踩过什么坑比如之前因为导出大文件导致内存溢出把它写进Background或支持文件里AI就不会重蹈覆辙。Trellis文档里对支持文件建议用puft add方式加入任务本质上就是往任务的数据包里塞文件为AI补粮草。这一步一定要认真做反正我都养成了一套固定仪式写出规范化支持文件结构编号、路径、说明、优先级然后才是真正的内容。磨刀不误砍柴工规范文件准备得越充分后面的执行阶段就越顺滑。4. Trellis的完整工作流从Issue到可合并PR的一次实战复盘这一节直接复盘一次我用Trellis处理真实需求的完整过程让大家对整套工作流有全貌认知。项目背景是用Python FastAPI写的一个用户运营后台需求是添加用户标签批量导入功能。4.1 初始化任务trellis init与puft addTrellis在你已有的Git仓库里工作。对每个新需求第一步是在项目根目录下初始化一个新的Trellis任务上下文。我用的是它的trellis init命令在这里给它一个任务名称然后指定加载哪些已有的tuft文件作为参考。之后我用puft add把相关文件挂到当前任务下。这一步有点像给AI开材料清单。我在这个需求里挂入了docs/api/v1/users_tag.http—— 已有的用户标签相关的API定义文件models/tag.py—— 现有标签数据库模型定义services/tag_import.py—— 之前已经写好的导入服务代码让AI参考风格随后Trellis会读取这些文件并将其连同我写的tuft规范一并纳入上下文。注意Trellis本身不会盲读仓库所有的组它会审慎地要求你确认哪些文件放行。这种白名单机制我觉得挺好——防止AI在几万行代码里随机捞鱼也能显著降低token消耗。4.2 规划阶段trellis plan与人工审批材料备齐后真正开始干活的第一个命令是trellis plan。它会调用你配置的LLM比如GPT-4o、Claude这类根据tuft文件里的要求和支持文件里的代码上下文产出一份详细的实现计划。这份计划里会包括对需求的理解和拆解计划修改的具体文件列表计划新增的文件和模块结构技术实现方案的要点潜在的边界情况和风险点第一次跑的时候我抱着看看它想干嘛的心态把计划从头读了一遍。它整体结构还行但确实有地方越界了——它计划在一个公共工具类里新增一个数据清洗函数而我们的规范里明确说了禁止改动公共目录。我在计划审查阶段直接写了一句意见禁止修改utils/目录下的任何文件清洗逻辑放置在services/tag_import_cleaner.py中。然后执行trellis revise让AI按这个反馈重新生成计划。第二次的计划就老老实实不碰公共目录。这一步就是第2节说的给AI装上辅助轮的关键节点先让它交底你再拍板。只要你抓住规划阶段后面就不会翻大车。4.3 TDD循环trellis test与trellis implement计划批准之后进入执行阶段。Trellis执行阶段的设计很有特色它是按TDD循环来组织的。先由AI编写失败的测试然后运行测试确认它们失败再编写实际代码让测试通过。它拆成了两个命令trellis test生成测试trellis implement编写实现。在实践里AI总是会先给出测试文件中的核心参数和Mock方案这是确保后续实现能对齐的关键一步。实际跑的时候trellis test生成的测试覆盖了这些场景正常批量导入、部分数据格式非法、权限不足、超大文件。这一点很值得表扬——它写出来的测试不是自嗨式的空测试而是真的覆盖了验收标准里的核心项。测试跑完后是红符合预期。然后是trellis implementAI会根据测试里定义的期望开始写实现代码。我观察了一下它的行为在实现过程中它会频繁回看tuft文件里的Guardrails虽然没有强制但过程中显然经过模型精神检查。跑完后重新执行测试全绿。这个流程走下来最大的感受是Trellis的TDD循环实质上是在用可执行的测试作为规范的一部分来兜底。测试不是简单的前置步骤而是验收标准的具体化。比如tuft里写超大文件必须拆分处理测试里就会有对应的用例实现如果不满足这个用例测试就是红AI就必须修。这让规范从文字变成了可以自动校验的程序可靠性和纯提示词不可同日而语。4.4 代码审查与合并人工检查仍然不可替代Trellis跑完整个流程后最终交付的内容包含新增的测试文件、实现代码、一个执行摘要。我仍会逐文件做代码审查检查逻辑边界是否在评审中出现误判、是否有伪完成的痕迹。曾经有一次AI在处理边界条件后没有测试是否包含连续导入两个不同文件的场景我自己在审查时发现并在验收标准里追加了一条之后后面再跑这个任务的变体时它就不会漏了。这也是我想强调的一点Trellis不会替代人它只是把人的注意力集中在真正需要判断的地方。你不需要逐行审AI写的工具函数有没有偷懒了但你要做的验收判断Trellis给你明确的位置和可执行的标准这能省掉大量的无效纠结。5. Trellis的边界与适用场景什么项目值得装辅助轮我在社区里看到不少Trellis是不是银弹的争论。我的观点很明确它是工具不是银弹。它针对的问题域是明确的超出这个范围反而会让你更累。5.1 适合Trellis的典型场景从我的实践来看适合引入Trellis的项目有下面几个共同特征有明确的业务规则和验收标准。比如结算系统、权限系统、审批流、报表系统等。这类项目的对与错是清晰可判的正好适合写成Guardrails和Acceptance Criteria。架构分层严格不允许随意破坏。比如公司里有统一的技术规范文档、有Code Owner机制、有强制Review流程。Trellis能把这类约束前置AI不至于到提交PR时才发现架构全乱了。任务可以拆解为相对独立的模块。如果你一次只让Trellis处理一个模块、一个服务、一个功能点它的效果最好。反过来如果你指望它一口气重构整个单体应用那它的规划和审查成本会高到不可用。愿意在需求分析和规范编写上花时间的团队。Trellis不是拿来提效的——它是拿前期的慢换后期的稳。如果团队没有业务分析师或技术经理愿意把需求翻译成tuft上这套就跑不起来。5.2 不适合Trellis的场景下面这些场景我建议你就别折腾Trellis了直接对话式编程更省心探索性、原型验证类工作。你只是想试试一个想法可不可行、跑通一个Demo、验证某个技术方案此时写完整tuft成本太高了。Trellis的严谨流程反而束缚手脚。需求极简、一次性任务。比如帮我把Json转成CSV格式这种十分钟搞定的脚本级需求让AI直接生成并人工看一眼即可完全没必要走规划-审批-测试-实现的完整流程。团队没有时间维护规范文件。如果你写了tuft之后就扔在那里不更新AI基于过期的规范干活效果比没有规范更糟糕——它会信誓旦旦地按错误规范执行你还得花精力揪出它的合规错误。5.3 横向对比需求中提到的各种AI编程工具热搜词里有人在讨论Cursor、Windsurf、Copilot、Trae谁好谁坏。我实际用下来它们和Trellis其实根本不在一个维度上。Cursor、Windsurf、Copilot、Trae是驾驶舱它们的核心是让你更好地操控AI提供代码补全、对话、多文件编辑的能力。Trellis是轨道和护栏它负责定义目的地、约束路线、防止翻车。把Trellis和Cursors这类工具放在一起用才是完整的体验用Cursor提供AI能力用Trellis定义AI行为边界和验收标准。单纯比较哪家AI工具最厉害在项目规模变大之后意义不大——因为它们的编码能力上限最终取决于你有没有一套像Trellis这样的任务工程流程去约束它。5.4 API与编程Trellis对AI Agent生态的定位热搜词里还有AI Agent与PLC编程AI编程FPGA这类提问Trellis的思路同样能提供启发。Trellis本质上是一个AI Agent任务工程框架它的核心贡献不是写代码的能力而是把执行过程标准化、可控化。所以它的能力边界其实不局限于纯软件代码——只要目标可以拆成输入→规划→测试→实现→验证的结构Trellis这套方法论就能套用。我个人判断未来AI编程的竞争焦点不只在模型本身而在于谁能更好地把任务需求转化为AI可执行的严谨规范。Trellis的这个定位让它在这场竞赛里占据了很特殊的位置——它不跟模型竞争它做的是模型的制度环境。6. 踩坑记录与使用心得Trellis实践中的真实体验最后这部分我集中整理实操过程中踩过的坑和攒下的经验每一个都是真金白银换来的。6.1 规范过细和过粗都是灾难关键在于刚好的粒度我一开始写tuft的时候恨不得把每个函数命名、每个变量大小写都给AI规定好。结果发现完全不行——规范过细AI的自主空间被压得太死遇到稍微复杂点的场景就得频繁回问我整个流程变得极其笨重人反而成了瓶颈。后来我又走向另一个极端把规范写得特别泛只有一两句请注意代码质量。结果AI直接放飞自我架构跑偏。现在的经验是规定边界不规定实现。Guardrails管住什么不能碰什么必须用验收标准管住最终长什么样至于中间你怎么实现、怎么组织代码结构那是AI的事我不越权。这个刚好的粒度需要磨合但值得花时间找——它是整个Trellis流程使用体验好坏的胜负手。6.2 模型选择影响巨大不是所有LLM都适合走流程Trellis的规划、测试、实现三段式流程对底层模型的能力要求不太一样。我实测下来在规划阶段需要模型有较强的长文本理解能力和全局视野Claude系列的表现好于其他模型它生成的规划更有条理。在测试生成阶段需要模型有良好的测试直觉GPT-4级别足够了重点是覆盖率。在实现阶段关键是模型能否精准遵循已有代码风格这块反而是小型、专业的代码模型表现更让人惊喜因为它不会自作聪明。我现在的建议是如果你用的是单一模型尽量选择当前主流的多模态旗舰款如果你的Trellis支持配置多模型可以把规划与实现分开指定能明显提升体验。另外注意温度参数在Trellis的完整流程里我建议把模型温度调低减少随机挥发的灵感。6.3 团队落地时的流程设计建议Trellis落地到团队不是装个CLI就算完了。它要求团队变更工作方式从把需求丢给AI变成把需求翻译成tuft规范。这不是开发一个层面的事建议按这个顺序推进从一个模块开始试点。选一个边界清晰、规范容易定义的模块跑通全流程积累团队经验和自信。建立tuft模板库。把每次写得好、用得顺的规范沉淀成模板后续同类任务直接套模板改参数大幅降低每次从零写的成本。明确Review角色的职责。Trellis里的规划审批、代码审查、验收确认都需要人来负责。团队里要有明确的Code Owner不能人人都有权打回计划否则流程会乱。记录AI违规日志。我建议对AI违反Guardrails被纠正的情况做统计。哪个位置最容易越界哪类措辞最容易让AI误解这些数据会帮你把规范写得越来越精准。6.4 一点私人心得Trellis改变的不只是代码产出用了几个月Trellis之后我有个挺明显的感受它改变的远不止代码产出更是团队里人和AI的关系。以前我们看AI像看一个聪明但不太靠谱的实习生——活能干但得随时提防着。用Trellis跑起来后AI更像一个外包开发组你给清楚需求文档和接口规范它能稳定交付你按验收标准做检查就行。这种心态转变非常微妙但很关键它把很多研发心里那头AI到底靠不靠谱的疑虑给缓解了因为不靠谱的部分被流程拦在了前面交付到你手里的是已经经过多层校验的结果。当然Trellis不是万能的。它解决的是AI编码的可控性问题而需求本身对不对架构合不合理这种更高层的决策仍然需要人来判断。辅助轮只能保证车子不翻不能替你决定往哪儿开。如果你正被AI编程的不可控折磨而且你愿意先花点时间把规范写清楚我真心建议你试试Trellis——去项目仓库把代码拉下来按文档跑通了一个最小任务之后再回来看看这篇文章讲的那些细节你会收获比我这篇分享多得多。