我好像发现了省 tokens 的方法

[sskycn]

只要写的需要是足够清析明了的，用 5.6 sol heigh 也用不了多少 tokens.

需求文档需要详细到我们以前给开发人员写的文档一样，至少详细列出目标，限制，验收规则；如果能详细到具体的实现，那就更省。

[wew3]

要不咱先搞清楚 height 、high 这俩词再来发帖？

[sskycn]

手误，打字的时候经常会有错别字，不好意思。需求也经常写成需要了。

[moooooooo]

你可以用 plan 模式去规划,也可以在 plan 模式的基础上加个市面上的 harness 插件体验下效果

[a0210077]

"如果能详细到具体的实现" 这个步骤可以交给 AI 去细化
常见路数：GPT5.6 sol 写计划定需求边界，然后控制其他更便宜模型去实现，最后 GPT 验收

[sskycn]

我昨天只用了 3%的量实现了 17 个提交。

https://github.com/sskycn/netbadb/commits/main/

[sskycn]

我用网页版 pro 做规划，5.6 sol high 写代码。

[yidinghe]

所以说程序员的表达能力会带来巨大的差别。

[testsb]

参考一下 https://codexradar.com/ 里的模型智商选模型吧

sol medium / Terra max / Luna max / DS flash 跟你的 high 效果差不了多少

需求/实现细节定死以后，到了纯编码阶段，中级和高级模型(或思考强度)差别不大，但是高级模型贵很多，高级模型更适合用于制定方案/解决问题

[sskycn]

@testsb 是的，所以还可以更省。写 android app 用 luna 又快又省。

[gorvey]

我现在喜欢用 girll-me 做规划，写出来的东西非常符合预期，基本不需要修改

[foryou2023]

赞成的，个人的学习到的一个理念如果文档写的足够详细的话，入门级的模型也能很好的做事的。

理论上教程写的足够详细的话，一个外行也可以执行的很好的。

现在做项目都是先 plan 模式，让模型写好文档，多次 review 看看哪里是否有遗漏的地方，这样干活效率高不少。

[foryou2023]

@foryou2023 人与人之间传递信息一样，传递的越详细，做事起来就明确。

[Rorysky]

这样很好，但其实是不同范式的 vibe coding
尤其任务复杂了之后，人介入越多，效率越低

[94]

不都是这样么，先是 flash/luna 把粗略想法整对话理成需求，然后用高级模型把需求输出成多阶段计划和子任务。最后再多开 flash/luna 按照不同阶段的子任务清单做实施。

[woshishui2022]

@gorvey codex 用 grill-me 体验很差，都不能交互； codex 自带的 plan 模式感觉有点不够

[gorvey]

@woshishui2022 在原版上改造一下就可以支持了，我还做了批量提问，体验可以说是非常 nice

[jko123]

人力 token 代替电力 token ，我就知道有免费 token 的方法

[sskycn]

不把需求说清楚，就需要不断返工，开始爽那一下，不值得。 @jko123

[xyooyx]

@woshishui2022 codex 有 grill-me 吗。。我一直以为等价的就是 plan mode

[xyooyx]

人脑和外脑之间有一个楔子

[kkwa56188]

token 是吧/doge
让我看看到第几楼会出现 翻译话语权爱好者 赶过来

[heftyMan]

那不是自己偷懒吗？

[woshishui2022]

@xyooyx #19 不是自带的，自己装的 skill
@gorvey 大概怎么改的？我准备问问 AI

[Tokin]

肯定哇，要么费自己脑子，要么费 AI 脑子（钱）。。。自己的脑力也是钱

[gorvey]

@woshishui2022 #23 让 codex 修改 grill-me skill 文件，提问时使用 request_user_input 工具呈现组件提问

[Blulotus]

@woshishui2022 这个配置开起来，然后全局规则让他用 request_user_input 工具问问题： [When `request_user_input` is available, use it for each question without repeating the same question in commentary or consecutive tool calls.]

```
[features]
default_mode_request_user_input = true
```

[woshishui2022]

@Blulotus @Blulotus 实测有效，感谢

[calmlyman]

@wew3 你是真煞风景，明眼人都知道打错了

[admin948]

是这样的，我之前用的时候也发现了，因为公司项目太复杂了，同一个业务有很多条不同的调用路径。

最开始让 AI 改 BUG 时，我是直接描述 BUG ，然后让它改，这时候它往往需要耗费非常多的上下文和时间去厘清到底是哪个路径出的问题，这时候经常出现因为上下文太大触发了压缩，导致它的信息不全，从而误判 BUG 原因；或者就算没有触发压缩，也会因为读的代码太多，开始有点混乱，找错了路径，修复错地方是经常发生。

后来我是直接把导致 BUG 出现的完整路径，甚至是对应的哪个文件，哪个方法都一起发给 AI ,这下分析的就飞快，而且基本不会出错。

但是这样，我自己都已经锊了一遍，再深入一点我自己就已经找到问题在哪儿了，顺手就能给修复了

[LeftNight]

简单任务直接干，复杂任务 plan

[Bapper]

不就相当于人脑先做了一部分

[fywsky]

一句话就是：自己干得越多，AI 就越省。
换句话说：自己全干了，AI 就完全可以不用了。