把整个仓库塞给 AI，为什么我花了更多 Token，却得到更含糊的架构建议？ 在 Nathan AI Lab，我会先判断问题需要全量实现，还是只需要结构导航… · @KOF97AI · TwKit

@KOF97AI

把整个仓库塞给 AI，为什么我花了更多 Token，却得到更含糊的架构建议？ 在 Nathan AI Lab，我会先判断问题需要全量实现，还是只需要结构导航；Repomix 是打包工具，不是让上下文越多越好的理由，“省七成”也必须由自己的仓库数据证明。 1. **先画问题范围再打包** 要查支付回调，我会优先选路由、订单状态、签名校验和相关测试，排除构建产物、缓存和大数据文件。先看打包文件清单和令牌分布，确认没有漏掉关键依赖；密钥文件在输入边界排除，不能全靠输出后的自动检查兜底。 2. **骨架用于找路实现用于定案** [Repomix 官方说明](https://repomix.com/guide/faq)介绍了 --compress 用 Tree-sitter 保留关键结构。我会先用骨架定位接口，再补读目标函数原文；压缩会丢实现细节，不能只凭签名就判断鉴权、事务或并发行为正确。 3. **用同题比较量出收益** 同一份问题分别喂原始相关文件和压缩结果，记录输入 Token、回答遗漏与返工次数。省量比例按“原始减压缩，再除原始”计算；如果省了输入却多出三轮追问，就把补读成本也算进去，不拿别人的百分比冒充我的结果。 收藏配图里的三个动作，下一次动手时逐项对照。 我的上下文原则：删掉无关信息是节省，删掉判断依据只是把成本挪到下一轮。 #AI编程 #独立开发 #开发者日常 #出海搞钱 #ClaudeCode

曝光 90 · 评论 2 · 点赞 1 · 书签 0