即刻App年轻人的同好社区
下载
6.1 Sol 相当于小 Astra，设计方面比 Opus 5.5 / Sonnet 5.5 差一些，但更便宜。追求质感 用 opus 5.5，追求日常用 6.1 Sol
价格更便宜，适合干活：0.1 美刀缓存读， 2美刀的输入，10美刀的输出
价格更便宜，适合干活：0.1 美刀缓存读， 2美刀的输入，10美刀的输出
1 00
GPT 最喜欢过度设计和护栏了，每当你完成功能后，会发现护栏多、代码分叉多、一份能力跑多个地方。还有旧的无用的失效过期历史还在兼容。功能能跑，但是token消耗高出刚开始的几倍。
最好的方式，就是在规划的时候，提前把这些规划好，修改功能完成以后说：本次任务完成后，给我本次任务完成前后的流程图对比。来看看是不是多干活了。
还可以加一个SKILL来做规划，提示词如下：
## 目标
[填写要解决的问题、期望结果和具体要求]
根据现有项目，为上述需求设计一套可以直接用于开发实施的改动方案。
要求：
- 完整覆盖本次需求；
- 只包含实现需求所必需的改动；
- 不扩展无关能力；
- 不直接编写实现代码。
## 输入依据
以我提供的需求、项目结构和现有代码为准。
- 先检查需求前提、现有实现和依赖关系。
- 不凭空假设不存在的模块或能力。
- 影响方案成立的信息缺失时明确指出；不影响结果的细节自行合理处理。
## 范围与边界
- 只调整实现本次需求所必需的内容。
- 未被本次需求影响的行为、接口和模块保持不变。
- 不为未经确认的未来需求预留扩展。
- 不直接编写代码，只输出方案设计。
## 设计标准
- 流程保持单向依赖。
- 模块可以独立测试。
- 对外接口保持最小。
- 遵循 SRP、OCP、ISP、DRY、KISS、YAGNI。
- 避免过度代码、重复抽象和没有实际收益的护栏设计。
- 优先复用现有能力；只有职责或依赖确实不同，才新增模块。
## 方案取舍
存在多种可行方案时，优先选择：
1. 改动范围最小；
2. 与现有结构一致；
3. 依赖和状态流向清晰；
4. 容易测试和回滚；
5. 代码与认知成本更低。
如果这些标准发生冲突，说明取舍及影响。
## 输出要求
只输出与本次任务有关的内容。
### 1. 项目结构变更
用项目树标注涉及的文件或模块：
- `[新增]`
- `[修改]`
- `[删除]`
- `[不动但受影响]`
每项用一句话说明职责，不罗列无关文件。
### 2. 流程与改动点
使用流程图：
- 先画主流程，标出本次改动位置；
- 再展开确有必要的子流程；
- 标明数据、状态和依赖的流向；
- 不展开没有发生变化的内部细节。
### 3. 文件与模块调整
按以下顺序说明，并以列表的方式呈现，只保留本次实际涉及的项目；没有的项目不要写出来，不要虚构设计：
- **共享状态**：哪些状态跨模块使用、由谁持有、由谁修改，为什么需要共享。
- **共用组件**：哪些能力被复用、复用方有哪些，为什么适合共用。
- **新增模块**：新增什么、负责什么、为什么不能放进现有模块。
- **修改模块**：修改什么、原因是什么、影响哪些调用方。
- **删除或收缩模块**：删除或缩减什么、为什么已经不需要。
- **接口变化**：新增、修改或删除哪些公开接口，以及调用方如何调整。
### 4. 本次方案自检
只检查本次新增、修改、删除的内容，以及被这些改动直接影响的现有模块，不审查无关代码。
检查本次方案是否：
- 引入了超出需求的模块、抽象、接口或防御逻辑；
- 产生新旧流程并存、逻辑失效或行为冲突；
- 增加不必要的跨层调用、双向依赖或模块耦合；
- 造成共享状态归属不清、隐式修改或跨请求污染；
- 新增与现有实现重复或高度相似的代码；
- 违反 SRP、OCP、ISP、DRY、KISS、YAGNI；
- 遗漏旧入口、调用方、测试或配置的同步调整。
只报告实际发现的问题。每项说明：
- **位置**：涉及哪个文件、模块或流程；
- **问题**：具体哪里不合理；
- **影响**：不调整会发生什么；
- **调整**：最小修改方式。
如果没有发现问题，写“本次方案未发现上述问题”，不要虚构风险
## 验收标准
方案应满足：
- 每项需求都能对应到具体流程和文件改动；
- 每个文件改动都有明确原因；
- 状态归属、依赖方向和公开接口清晰；
- 没有纳入本次需求之外的改造；
- 开发人员可以据此直接开始实现。
最好的方式，就是在规划的时候，提前把这些规划好，修改功能完成以后说：本次任务完成后，给我本次任务完成前后的流程图对比。来看看是不是多干活了。
还可以加一个SKILL来做规划，提示词如下：
## 目标
[填写要解决的问题、期望结果和具体要求]
根据现有项目，为上述需求设计一套可以直接用于开发实施的改动方案。
要求：
- 完整覆盖本次需求；
- 只包含实现需求所必需的改动；
- 不扩展无关能力；
- 不直接编写实现代码。
## 输入依据
以我提供的需求、项目结构和现有代码为准。
- 先检查需求前提、现有实现和依赖关系。
- 不凭空假设不存在的模块或能力。
- 影响方案成立的信息缺失时明确指出；不影响结果的细节自行合理处理。
## 范围与边界
- 只调整实现本次需求所必需的内容。
- 未被本次需求影响的行为、接口和模块保持不变。
- 不为未经确认的未来需求预留扩展。
- 不直接编写代码，只输出方案设计。
## 设计标准
- 流程保持单向依赖。
- 模块可以独立测试。
- 对外接口保持最小。
- 遵循 SRP、OCP、ISP、DRY、KISS、YAGNI。
- 避免过度代码、重复抽象和没有实际收益的护栏设计。
- 优先复用现有能力；只有职责或依赖确实不同，才新增模块。
## 方案取舍
存在多种可行方案时，优先选择：
1. 改动范围最小；
2. 与现有结构一致；
3. 依赖和状态流向清晰；
4. 容易测试和回滚；
5. 代码与认知成本更低。
如果这些标准发生冲突，说明取舍及影响。
## 输出要求
只输出与本次任务有关的内容。
### 1. 项目结构变更
用项目树标注涉及的文件或模块：
- `[新增]`
- `[修改]`
- `[删除]`
- `[不动但受影响]`
每项用一句话说明职责，不罗列无关文件。
### 2. 流程与改动点
使用流程图：
- 先画主流程，标出本次改动位置；
- 再展开确有必要的子流程；
- 标明数据、状态和依赖的流向；
- 不展开没有发生变化的内部细节。
### 3. 文件与模块调整
按以下顺序说明，并以列表的方式呈现，只保留本次实际涉及的项目；没有的项目不要写出来，不要虚构设计：
- **共享状态**：哪些状态跨模块使用、由谁持有、由谁修改，为什么需要共享。
- **共用组件**：哪些能力被复用、复用方有哪些，为什么适合共用。
- **新增模块**：新增什么、负责什么、为什么不能放进现有模块。
- **修改模块**：修改什么、原因是什么、影响哪些调用方。
- **删除或收缩模块**：删除或缩减什么、为什么已经不需要。
- **接口变化**：新增、修改或删除哪些公开接口，以及调用方如何调整。
### 4. 本次方案自检
只检查本次新增、修改、删除的内容，以及被这些改动直接影响的现有模块，不审查无关代码。
检查本次方案是否：
- 引入了超出需求的模块、抽象、接口或防御逻辑；
- 产生新旧流程并存、逻辑失效或行为冲突；
- 增加不必要的跨层调用、双向依赖或模块耦合；
- 造成共享状态归属不清、隐式修改或跨请求污染；
- 新增与现有实现重复或高度相似的代码；
- 违反 SRP、OCP、ISP、DRY、KISS、YAGNI；
- 遗漏旧入口、调用方、测试或配置的同步调整。
只报告实际发现的问题。每项说明：
- **位置**：涉及哪个文件、模块或流程；
- **问题**：具体哪里不合理；
- **影响**：不调整会发生什么；
- **调整**：最小修改方式。
如果没有发现问题，写“本次方案未发现上述问题”，不要虚构风险
## 验收标准
方案应满足：
- 每项需求都能对应到具体流程和文件改动；
- 每个文件改动都有明确原因；
- 状态归属、依赖方向和公开接口清晰；
- 没有纳入本次需求之外的改造；
- 开发人员可以据此直接开始实现。
9 31
jev热度很高，实用场景非常丰富，我尝试了在不同场景下验证，成功率比 ds v4.1 会低一些，成本会小一些。但是从业务整体角度来说，并不是最优选。特别是在业务场景下局限性较大（普遍适合非常稳定的场景，比如稳定的模板和意图路由），需要 LLM 进行兜底。有时候可能还不如直接LLM执行多判断多批次。
比如说我在日常采集场景下：我对结果要求比较高，中间过程如果使用 jev 大概每千条提效 8% 左右，但换来成功率和质量的降低。虽然成本下降了一些，相当于原来要1美刀，现在可能只有0.1 美刀左右。但是 1 美刀和 0.1 美刀对我而言，不会造成较大的成本波动。
但是 jev 这个场景的需求是非常需要的，可能过1~2周就会有大模型推出来，非常期待。
比如说我在日常采集场景下：我对结果要求比较高，中间过程如果使用 jev 大概每千条提效 8% 左右，但换来成功率和质量的降低。虽然成本下降了一些，相当于原来要1美刀，现在可能只有0.1 美刀左右。但是 1 美刀和 0.1 美刀对我而言，不会造成较大的成本波动。
但是 jev 这个场景的需求是非常需要的，可能过1~2周就会有大模型推出来，非常期待。
2 01
opencode go 使用的 glm-5.3-flash和 deepseek flash v4.1 与官方比真的是差太多了
1：不说人话
2：遵循指令度比较弱
3：编码能力远低于官方正常水平
只能说拿来做日常批量任务确实是比较省，用来coding还是有一段距离
1：不说人话
2：遵循指令度比较弱
3：编码能力远低于官方正常水平
只能说拿来做日常批量任务确实是比较省，用来coding还是有一段距离
1 00
一下午。GLM 5.3 flash，三四千万 token。换 DeepSeek 4.1 flash，五亿起步。一个拿勺子舀，一个把水管拧开。
但用法不一样。DeepSeek 细：需求模糊先跟你划边界，你想不到的角落它顺手扫一遍，五亿不是白烧的。GLM 像人在说话，话少，够用就停。
反倒是 GPT 变味了。以前嫌国模不够聪明，得我盯着；现在嫌 GPT 太勤快，得我拦着。你说改个函数，它还你一个模块；每轮重读全文，越滚越多。
开会那种同事，你问一句，他讲三遍。
国模现在刚刚好——不多写，不少写，写完就停。前提是边界得写清楚，像交接文档。也要看场景：日常的活给它俩，要真稳，还得上 opus-5、sol。
zcode 打包代码这事，真不用过度解读。你不走它也有别的通道，代码总要出门。不放心就换开源，pi agent、t3code——但换车不换油。
模型拿你的代码训练是必然。最反差的是：你怕它拿，又需要它拿，才写得出你要的代码。
但用法不一样。DeepSeek 细：需求模糊先跟你划边界，你想不到的角落它顺手扫一遍，五亿不是白烧的。GLM 像人在说话，话少，够用就停。
反倒是 GPT 变味了。以前嫌国模不够聪明，得我盯着；现在嫌 GPT 太勤快，得我拦着。你说改个函数，它还你一个模块；每轮重读全文，越滚越多。
开会那种同事，你问一句，他讲三遍。
国模现在刚刚好——不多写，不少写，写完就停。前提是边界得写清楚，像交接文档。也要看场景：日常的活给它俩，要真稳，还得上 opus-5、sol。
zcode 打包代码这事，真不用过度解读。你不走它也有别的通道，代码总要出门。不放心就换开源，pi agent、t3code——但换车不换油。
模型拿你的代码训练是必然。最反差的是：你怕它拿，又需要它拿，才写得出你要的代码。
2 00
跑了20亿token，我发现最适合 deepseek flash 4.1的是 zcode。
没有 deepseek harness 因上下文过长牛头不对马嘴，没有因刷得太快导致信息噪音过多的问题
没有像 codex 那样兼容性很差，思考过程要么不停闪，要么看不到，输出的上下文信息很差
deepseek flash 4.1 我更倾向于写写小工具做爬虫和写作，或者让高阶模型（gpt-6、fable）规划、拆小任务和review。
没有 deepseek harness 因上下文过长牛头不对马嘴，没有因刷得太快导致信息噪音过多的问题
没有像 codex 那样兼容性很差，思考过程要么不停闪，要么看不到，输出的上下文信息很差
deepseek flash 4.1 我更倾向于写写小工具做爬虫和写作，或者让高阶模型（gpt-6、fable）规划、拆小任务和review。
11 90
扶不起阿斗的 Gemini 3.7 居然起飞了，10s 直出 threejs 游戏，你敢信？看附件视频，我在 gemini.google.com生成的
- 10s 复刻一个网页，你敢信？
- 10s 解读 Youtube 视频，你敢信？
- 10s ....
而且效果非常好，fable-5 跑规划，gemini flash 3.7 跑执行，这速度实在是太快了
- 10s 复刻一个网页，你敢信？
- 10s 解读 Youtube 视频，你敢信？
- 10s ....
而且效果非常好，fable-5 跑规划，gemini flash 3.7 跑执行，这速度实在是太快了
00:20
5 00