只要写的需要是足够清析明了的，用 5.6 sol heigh 也用不了多少 tokens.
需求文档需要详细到我们以前给开发人员写的文档一样，至少详细列出目标，限制，验收规则；如果能详细到具体的实现，那就更省。
 |
1
wew3 15h 18m ago
要不咱先搞清楚 height 、high 这俩词再来发帖？
|
 |
2
sskycn OP 手误，打字的时候经常会有错别字，不好意思。需求也经常写成需要了。
|
 |
3
moooooooo 15h 15m ago
你可以用 plan 模式去规划,也可以在 plan 模式的基础上加个市面上的 harness 插件体验下效果
|
 |
4
a0210077 15h 12m ago
"如果能详细到具体的实现" 这个步骤可以交给 AI 去细化
常见路数：GPT5.6 sol 写计划定需求边界，然后控制其他更便宜模型去实现，最后 GPT 验收 |
|
5
sskycn OP |
|
6
sskycn OP 我用网页版 pro 做规划，5.6 sol high 写代码。
|
 |
7
yidinghe PRO 所以说程序员的表达能力会带来巨大的差别。
|
 |
8
testsb 15h 1m ago
参考一下 https://codexradar.com/ 里的模型智商选模型吧
sol medium / Terra max / Luna max / DS flash 跟你的 high 效果差不了多少 需求/实现细节定死以后，到了纯编码阶段，中级和高级模型(或思考强度)差别不大，但是高级模型贵很多，高级模型更适合用于制定方案/解决问题 |
 |
10
gorvey 14h 36m ago  1
我现在喜欢用 girll-me 做规划，写出来的东西非常符合预期，基本不需要修改
|
 |
11
foryou2023 13h 44m ago
赞成的，个人的学习到的一个理念如果文档写的足够详细的话，入门级的模型也能很好的做事的。
理论上教程写的足够详细的话，一个外行也可以执行的很好的。 现在做项目都是先 plan 模式，让模型写好文档，多次 review 看看哪里是否有遗漏的地方，这样干活效率高不少。 |
|
12
foryou2023 13h 42m ago
@foryou2023 人与人之间传递信息一样，传递的越详细，做事起来就明确。
|
 |
13
Rorysky 13h 29m ago
这样很好，但其实是不同范式的 vibe coding
尤其任务复杂了之后，人介入越多，效率越低 |
 |
14
94 13h 28m ago
不都是这样么，先是 flash/luna 把粗略想法整对话理成需求，然后用高级模型把需求输出成多阶段计划和子任务。最后再多开 flash/luna 按照不同阶段的子任务清单做实施。
|
 |
15
woshishui2022 12h 58m ago
@gorvey codex 用 grill-me 体验很差，都不能交互； codex 自带的 plan 模式感觉有点不够
|
|
16
gorvey 12h 40m ago
@woshishui2022 在原版上改造一下就可以支持了，我还做了批量提问，体验可以说是非常 nice
|
 |
17
jko123 12h 24m ago
人力 token 代替电力 token ，我就知道有免费 token 的方法
|
 |
19
xyooyx 12h 2m ago
@woshishui2022 codex 有 grill-me 吗。。我一直以为等价的就是 plan mode
|
|
20
xyooyx 12h 1m ago
人脑和外脑之间有一个楔子
|
 |
21
kkwa56188 11h 56m ago
token 是吧/doge
让我看看到第几楼会出现 翻译话语权爱好者 赶过来 |
 |
22
heftyMan 11h 51m ago
那不是自己偷懒吗？
|
|
23
woshishui2022 11h 42m ago
|
 |
24
Tokin 11h 40m ago
肯定哇，要么费自己脑子，要么费 AI 脑子（钱）。。。自己的脑力也是钱
 |
|
25
gorvey 11h 39m ago 1
@woshishui2022 #23 让 codex 修改 grill-me skill 文件，提问时使用 request_user_input 工具呈现组件提问
|
 |
26
Blulotus 11h 18m ago 2
@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 ``` |
|
27
woshishui2022 10h 38m ago
|
 |
29
admin948 10h 15m ago
是这样的，我之前用的时候也发现了，因为公司项目太复杂了，同一个业务有很多条不同的调用路径。
最开始让 AI 改 BUG 时，我是直接描述 BUG ，然后让它改，这时候它往往需要耗费非常多的上下文和时间去厘清到底是哪个路径出的问题，这时候经常出现因为上下文太大触发了压缩，导致它的信息不全，从而误判 BUG 原因；或者就算没有触发压缩，也会因为读的代码太多，开始有点混乱，找错了路径，修复错地方是经常发生。 后来我是直接把导致 BUG 出现的完整路径，甚至是对应的哪个文件，哪个方法都一起发给 AI ,这下分析的就飞快，而且基本不会出错。 但是这样，我自己都已经锊了一遍，再深入一点我自己就已经找到问题在哪儿了，顺手就能给修复了 |
 |
30
LeftNight 9h 55m ago
简单任务直接干，复杂任务 plan
|
 |
31
Bapper 6h 28m ago
不就相当于人脑先做了一部分
|
 |
32
fywsky 3h 29m ago
一句话就是：自己干得越多，AI 就越省。
换句话说：自己全干了，AI 就完全可以不用了。 |
Select Language