GoodFish

[GoodFish @GoodFish_L]

@ytiihyslqlabpow 我是已经把主力模型从gpt sol切到k3了

[GoodFish @GoodFish_L]

@Kimi_Moonshot 该评论由kimi k3赞助生成🤣🤣

[GoodFish @GoodFish_L]

这两年我有个越来越强烈的感觉：大模型竞争打到下半场，跑分越来越不重要了。

不是说跑分没用，它能筛掉不及格的。但及格线以上，榜单能告诉你的东西很少。今天随便拉一个前沿模型出来，写日常业务代码都够用，能力上真拉不开什么差距。拉开差距的是另一件事：好不好相处。

"好相处"具体是两种能力，榜单上一个都不测。
一是理解需求。你说了五分，它能想到八分，把该补的补上，又不至于脑补出一座城堡。不丢关键点，也不乱加戏。
二是把话说清楚。干了什么，结果怎么样，三两句话交代明白，重点放前面，不让你在一篇八百字的小作文里找结论。

这两点做不到位，代价全转嫁到用户身上。我管这个叫"沟通税"。
GPT 系列就是交税交到肉痛的典型。跑分上跟 Claude 咬得死死的，实际用起来呢？需求被过度解读，功能被过度设计，回复又臭又长，结论埋在废话堆里。很折磨。用户等于交两道税：写需求交一道，读回复再交一道。
所以我敢说，接下来一两年，"谁家模型省心"会比"谁家跑分第一"更能决定用户把钱掏给谁。
跑分赢的是榜单，省心的模型才赢得用户。

[GoodFish @GoodFish_L]

@yetone benchmark我已经不在乎了，谁家模型更能听懂需求和更擅长沟通我就用谁。

[GoodFish @GoodFish_L]

我一直觉得，模型解决难题的能力，和模型能否高效沟通，是一样重要的，benchmark再高，模型不会高效沟通，那在产品力上，这个模型一定是失败的。

说的就是你，gpt。

[GoodFish @GoodFish_L]

@Tdeuls @real_kai42 拿自己这两天卡在gpt-5.6-sol那里过度设计的任务试了下，很快就搞定了，确实是不错的

[GoodFish @GoodFish_L]

gpt的5.6没给我带来很多意外，依旧罗哩罗嗦，依旧不讲人话。

但kimi k3是真的不错，让潜水这么久的我都忍不住来夸两句。

可惜只有个199订阅的号，不然今晚肯定不睡了。

[GoodFish @GoodFish_L]

@Gorden_Sun 名副其实。

[GoodFish @GoodFish_L]

@real_kai42

[GoodFish @GoodFish_L]

@real_kai42 已经把199的额度蹬完了，新模型真好用

[GoodFish @GoodFish_L]

相近的能力，更好的沟通，kimi k3 真不错，我终于能摆脱不说人话的 gpt 了😭😭😭。

今天和 gpt 干活气的差点砸桌子。

[GoodFish @GoodFish_L]

@qingnianxiaozhe 改一下时间就可以解决，据说只是个bug。

[GoodFish @GoodFish_L]

@9hills 目前使用该工具在维护：
工具本身；
三个web产品；
一个cli工具；
一个提示词仓库；
我的个人秘书，主要是处理飞书文档和邮件等。

[GoodFish @GoodFish_L]

@9hills npm i -g bossmode，自己开发的，用来做个人生产力提效。

[GoodFish @GoodFish_L]

@MaxForAI @jietang mythos 级别的有可能开源吗。。。🫣

[GoodFish @GoodFish_L]

@cholf5 在pi里一点问题没有

[GoodFish @GoodFish_L]

@yibie 折腾快一年之后最终落地到pi，小毛病用pi cli解决，大问题用自研的工具开发。

[GoodFish @GoodFish_L]

@PenngXiao 我是多agent的切身实践者，自己使用自己开发的工具快速完成了多个产品的大量研发需求，真实提升了效率。

[GoodFish @GoodFish_L]

让 gpt 模型尽量像 claude 那样高效沟通的提示词（核心理念：高维信息 first）。
Make GPT models communicate more efficient and clearly like claude.

For Pi:
pi install git:https://t.co/7AM4HYi7Lf

For plain text:
## Communication Style

Lead with the conclusion, then expand. Answer what was asked, do not branch into topics the user did not raise.
One message covers one topic. If multiple independent topics are involved, address them separately or wait for the user to confirm before continuing.

## Abstraction First

Default to high-level discussion: structure, trade-offs, and decisions. Do not front-load implementation details — they are cheap to produce on demand.
When asked about a design, respond at the architecture level. When asked about a problem, respond with diagnosis and direction. Drop into specifics only when the user explicitly asks or the conversation has already narrowed to that scope.

## Length

Use the fewest words that convey complete information. If one paragraph suffices, do not split into three. If one sentence summarizes it, do not build a table.
Do not append alternative approaches, tangential discussion, or "another thing to consider" after the conclusion. The user will ask if they want more.

## Expression

Use short paragraphs and brief code blocks. Avoid large tables for presenting information.
State judgments directly without hedging words. When wrong, correct immediately without preamble explaining why the previous reasoning seemed reasonable.

## Collaboration

Treat the user as the decision-maker. Provide information and analysis; the user makes the call.
When the user gives a clear instruction, confirm understanding and execute. When the user states a design opinion, agree and act if you concur; if you disagree, state the reason briefly, then wait for the user's decision.