即刻App年轻人的同好社区
下载
AI探索站
111355人已经加入
- Andrej Karpathy 最新的视频，我看了两三遍。比较认同的一个观点是：Vibe Coding 可以提升下限，而Agentic Engineering 可以提升上限。这两个概念都是他创建的，最近我的思考是有了AI Coding 实现一些初级的软件更容易了，但是要实现高质量的软件产品，依旧需要卓越的设计和工程能力，这是工程师们的晋级方向。
比较受启发的一个观点是：他引用了别人的一句话（看第一遍时以为是他说的，心想这人怎么这么擅长创造金句），你可以外包你的思考（Thinking），但无法外包你的理解（Understanding）。他这里所说的思考是指一些信息收集、信息处理的工作。但真正做些一些事情，是需要很深的理解这到底是什么，为什么会这样，在这个基础上，才能做出好的设计。
原始视频：youtu.be
74 927 - 真的哭死！现在流量多贵呀，竟然还有top级的公众号愿意免费提到我的过去作品Chatbox。女生的故事也让人感动。希望Chatbox现在的团队能越做越好吧。
一个二本的女生，用免费的AI考上了北大。
183 1511 - 几行prompt，让你的DeepSeek v4 pro胜过Opus 4.7！
X上看到有人分析了DeepSeek v4 pro在工具调用上出现的问题，好消息是这些错误不多且是有固定模式的，打个补丁就能有效改善。原作者说在他们自己内部的eval上，改良后的DS，10次中有6次胜过Opus 4.7。
因为我自己用的是Hermes，在不fork harness来改的情况下，我能动的只有system prompt。所以应该达不到原文中战胜Opus的程度，可能能打个平手吧。我让AI协助我梳理了一些在system prompting层就可以修改的点，可以直接放到你的agent里使用（经过Opus 4.7和Gemini两重校验）：
# Tool Calling Rules
When calling tools, follow these rules strictly. They override any conflicting habits from chat training.
## Argument formatting
1. **Omit optional fields you don't need.** Do not send `null`, `""`, `{}`, or `[]` as a placeholder. If a field is optional and you have no value, leave it out of the JSON entirely.
2. **Match the container type exactly.**
- Array fields take JSON arrays: `["a", "b"]`, never `"[\"a\",\"b\"]"` (string), never `{}` (object), never `"foo"` (bare string).
- Single-element arrays still need brackets: `["foo"]`, not `"foo"`.
- Object fields take JSON objects, not arrays or strings.
3. **Strings are raw strings.** Do not wrap values in extra quotes, code fences, or markdown.
4. **Numbers and booleans are unquoted.** `30`, not `"30"`. `true`, not `"true"`.
## Paths and identifiers
5. **File paths, URLs, IDs, and similar fields go to system functions, not chat output.** Never format them as markdown links, never wrap them in backticks, never add explanatory parentheses.
Correct: `"/Users/me/notes.md"`
Wrong: `"[notes.md](notes.md)"`
Wrong: `` "`/Users/me/notes.md`" ``
Wrong: `"/Users/me/notes.md (the notes file)"`
6. **If a tool description says "path", treat it as input to a filesystem call.** No formatting, no decoration.
## Related parameters
7. **When a tool has paired parameters (e.g., offset + limit, start + end, from + to), provide both or neither.** Read the description — if two fields work together, half the pair often produces an error.
## Recovery
8. **If a tool returns a validation error, read the error message carefully and fix only what it complains about.** Do not rewrite the whole call. Do not retry the same arguments.
9. **If a tool returns a "Note:" with a defaulted value, that's informational, not an error.** Continue the task. If the default is wrong, retry with the correct explicit value.
## Tool selection
10. **Use the tool whose description matches your intent most specifically.** Don't reach for `shellCommand` if a dedicated tool exists. Don't reach for `execute_code` for things a single tool call can handle.
79 1762 - AI时代有一万种方法搞流量赚钱
说一个最简单最朴素最适合普通人的
那就是学习改变命运
但这不是花钱跟人学，也不学校找老师学，而是和AI学
方法如下：
0、下载牛马AI
1、找到一个你感兴趣的领域
2、向牛马AI提问，让他检索
3、找到好的学习资源，看看大家都推荐什么
4、确定选中其中一个，开始连载学习
5、每天向AI提问，比如学周易吧，就从乾卦开始学
6、提问聊天互相学习，这样AI就有上下文了
7、实践费曼学习，利用skills让牛马AI总结，然后出图
8、牛马AI把图出了，然后让牛马AI给你配个标题和摘要
9、把图发到小红书
10、小红书一边涨粉，一边卖和这个领域相关的商品服务
比如你学周易，你就卖图书卖挂饰卖算命风水服务
比如你在了解茶艺，你就卖茶壶茶碗茶宠茶叶
你学啥，你就卖啥
样子给你打好了，你可以用这套方法去肆杀小红书，小绿书，ins，甚至pinterest了
赚钱搞流量咱不会，那聊天，打字，说话，咱还不会吗？
59 718 - 我越来越觉得，大多数人对“进步”的理解是错的。
有人以为进步靠资源，有钱就能搞研发，人多就能出成果，数据多就能训练出好模型。也有人认为进步靠运气，刚好踩中了风口，碰上了时代红利就能起飞。还有人觉得进步靠制度，只要规则对，结果自然来。
但如果你真的研究过任何一个从无到有的突破，你就会发现这些都不是根本原因。
进步真正的起点是一个人面对一个没人解决过的问题，闭着眼睛往前走了一步。这一步没有任何依据，没有任何保证，甚至大概率是错的。但它一旦被迈过去，从此世界就多了一条以前没有的路。
我们从小被教育做事情要有依据，要等有足够证据再下结论。这套方法论在稳定、重复、可预测的环境里十分管用，但在真正的创新面前就完全失效了。因为真正的新东西在刚出现的时候是没有任何依据的，它必须被凭空“猜”出来。
你可能觉得“猜”这个词太轻了，但仔细想想爱因斯坦的相对论是怎么来的？他先猜了一个“光速不变”，然后看这个猜测会推导出什么荒谬的结论后再去检验。达尔文的进化论呢？他是在没有基因概念、没有化石证据链的情况下，先猜了一个“物种通过自然选择演化”，然后用几十年的时间去寻找证据。
这就是“猜想与反驳”的核心逻辑，你观察一万只白天鹅也证明不了“所有天鹅都是白的”。真正的新知识，只能通过先猜、再证伪的方式产生。你提出一个猜测然后拼命试图推翻它。扛住了，它就暂时成立。扛不住，你就知道这条路不通，换下一个。
这个过程中还有一个极其重要的副产品，即错误不再是失败的证据，而是进步的燃料。每排除一个错误的猜测，你就离真相更近了一步。一个从来不犯错的人，本质上已经停止了进步。
把这件事想清楚之后，你再去看今天的AI就会有一个非常清醒的认识。现在的大模型本质上是一个巨大的模式匹配器，它读过全人类写的大部分东西，然后学会了“接下来该说什么”。你问它一个问题，它就在见过的所有答案的河床里，找出最有可能流过来的那个。它就算算得比人快一万倍，也永远不会在没有依据的地方，闭着眼睛往前走一步。
这意味着AI目前还只是一个超级学生，而非一个真正的创造者。它能把你教给它的东西用到极致，但没办法凭空想出一个你从没教过它、甚至你自己都没想到的假设。而人类最独特的能力，恰恰就是这个。
这就是为什么“问题是一定存在的”和“问题是可以被解决的”这两个信念，构成了进步最底层的动力。你只有相信问题存在，才会去找。你只有相信问题可以被解决，才会在找不到的时候继续猜。绝大多数人停在第一步，因为他们默认“这个问题可能无解”。但“无解”是一个极其傲慢的结论，它意味着所有可能的解决方案在物理规律允许的范围内都已经被你穷举过了，你凭什么这么确定呢？
悲观主义之所以在逻辑上站不住脚，是因为它隐含了一个无法被证明的断言，即某些知识永远不可能被创造出来。你没法证明一个东西永远不会被发现，所以你每说一次“不可能”，其实都只是在暴露自己想象力的边界。
真正的乐观主义不是情绪上的积极，也不是骗自己说一切都会好起来。它基于一个可验证的事实，即人类已经解决了无数看似不可能的问题。我们把曾经动不动就夺走几千万人生命的天花灭绝了，我们把曾经以为永恒不变的地心说推翻了，我们把曾经需要几个月才能跨越的大洋压缩到了十几个小时。这些在它们发生之前都被人说过“不可能”，但后来都发生了。所以当我们面对今天的问题时，最理性的态度应该是“暂时还没找到办法”。
这个态度的转变会彻底改变一个人的行为模式，当你觉得一件事不可能时就会停止思考。而当你觉得“只是暂时还没找到办法”时就会持续地猜、试、错、再猜。即便循环几次后你可能依然没找到答案，但你在这个过程中获得的东西已经远远超过了那个答案本身。你学会了如何定义问题，如何提出假设，如何设计检验，如何从失败里提取信息。
我把这种能力称为“猜想肌肉”，它和任何肌肉一样，不用就退化。你越依赖标准答案，就越难产生新的猜测。你越害怕犯错，就越不敢提出那些看起来不靠谱的假设。但恰恰是那些看起来不靠谱的假设，偶尔会蹦出一个颠覆性的好东西。
现在回头看，人类文明其实只在两种状态之间摇摆。一种是静态，崇尚传统，依赖模仿，任何偏离都被视为威胁。这种状态能延续很久，因为它极其稳定。但其致命缺陷是当环境变化超出了经验的覆盖范围时，就会崩溃。另一种是动态，极其少见，鼓励批判，允许改变，核心是创造。人类只在极少数时期、极少数地方进入过这种状态，现在可能正在经历又一次窗口期。
问题是这个窗口很容易关上，因为维持批判性思维很累，维持创造很不舒服。AI的流畅、准确、永远不累，正在把我们往静态那边拉。因为你不需要再猜了，问它就行。你不需要再批判了，因为它给的答案通常就是最优解。
但最优解是过去的解，不是未来的解。未来的解，尚未被猜出来。
所以真正重要的问题并非“AI会不会取代人”，应是“在AI提供所有标准答案的时代，人还能不能保留瞎猜的勇气”。这可能是我们这一代人面临的最隐蔽、也最关键的挑战。
我从不担心AI太强，我担心的是我们会因为太舒服而忘记自己还有“闭着眼睛往前走一步”的能力，那个能力才是进步唯一的引擎。AI的未来也不应该沿着“更准、更快、更顺”的斜坡滑下去，那是一条通向静态文明的死路。真正的方向是通过建立独立的猜想生成器，用建设性错误代替最小化误差，让对抗式检验成为工作流的默认环节。
这意味着我们需要重新思考大模型的底层架构，重新定义智能的本质。如果知识增长的唯一途径是“猜想与反驳”，那么任何封闭系统都无法长期维持稳定。不管是公司、国家还是技术体系，只要你停止了创造新假设、批判旧假设，你就会退步。
这世上没有穷尽，所有“不可能”都只是“还没”。那一条条还没踩出来的路，就藏在每一次你觉得“这太离谱了但还是想试一试”的冲动里。259 32104 - 在 Manus 的时候跟同事一起推动过一次研发部的「AI 工具使用」大跃进，这个大跃进的主要工作之一是要设计好给 ai 看的规则，好让 ai 完全接管写代码的流程，大概在 2025 年 6 月份整个 manus 内部已经达成了所有新代码全部都由 ai 生成。
当时能用的 ai 工具还不多，我们主要用的是 cursor，claude code，code rabbit，规则就是给他们几个做的，我们工程团队每个方向排了一个人维护所有的给这些 ai 工具看的规则，我当时负责 iOS 端的这块工作，每天会有 30% 的工作时间用来 review code rabbit 根据 mr 和 mr comment 自动产生的一条一条式的记忆，维护每位同事加的 cursor rules，根据之前设计好的代码架构和大家的开发习惯/约定补 rules，在项目里的各种位置思考要不要加一个 rules，这个维护工作现在新潮一点的叫法就是 harness 设计。
回到从工程师的工作内容角度看这个事情，首先 Coding Agent 没带来代码运行逻辑上的变化，以前运行在机器上的 if else 现在还是 if else，他改变的是工程师的工作重心，工程师之前的工作宏观来说是两部分，第一部分是分析产品需求、沟通、设计抽象和架构，第二部分是写代码落地，验证以及 review。这两部分之间是由“设计抽象和架构”串联起来的，harness 设计工作的目的就是为了方便 agent 完全接管后面的部分（然后随着大家用的越来越熟练可以逐渐进化成让前面的除了沟通外的部分也由 ai 辅助来做），所以设计 harness 其实也就是在做这个“设计抽象和架构”工作。
这块工作是工程师工作中最难做的一部分，架构讨论在研发工作里非常难达成一致，往往大家都要吵架吵很久，最后效率高一点的方式很多时候是老板拍个板；这个工作有一些前人总结出来的经验，可以根据实际的项目节奏选择，但实际基本没法原样完全套用，基本上都要为了项目节奏再进行调整。有本老书管这个类似的情况叫“没有银弹”。
现在各种关于 skills，soul.md，agents.md，自进化，design.md 等等 harness 的讨论是一场扩圈到程序员圈子外的项目通用性架构设计讨论，结合前面的工作经验分析，这些讨论可能最终也不会有个能解决所有问题的结论，大家根据自己的使用需求以及服务场景自己定制，大家各自去考虑自己要做的 trade-off。Agent 是一台精密的仪器，人需要习惯他就是个会来带思考负担的东西。69 825
