良竹

@liangzhu_AI · 2026-10-25

只会调 API 的初级工程师正在被淘汰，真正值钱的是 Harness Engineering（外壳工程）。 底模到处都是，但在实际生产里，模型胡说八道、进入死循环、工具调用失败率高，全靠 harness 来兜底。 GitHub 上这门开源的 Harness 工程实战课干货极多： 涵盖了 Claude Code 运行架构、状态图（Graph）与循环机制、自愈 Agent 闭环，以及全链路可观测性。 14 节硬核大课加上 8 个端到端实战项目，全部开源免费。 想从调包侠进阶为 AI 架构师的朋友，抓紧存下慢慢学。 github 地址：https://github.com/walkinglabs/learn-harness-engineering

山景城小路

@Zen_with_AI · 2026-10-26

TradingAgents repo. 114,358⭐｜Python 小路读了一遍 TradingAgents 的 README，推荐给对多智能体感兴趣的朋友。 它是一个用 LLM 搭的交易研究框架，思路是把一家真实交易公司的分工，原样搬给一群智能体。 有如下3个智能体类别： 1. 分析师。基本面、情绪、新闻、技术面四个角色，同时各干各的，报告齐了才进入下一步。 2. 研究员。分多头和空头两派，对分析师的结论做结构化辩论，权衡收益和风险。 3. 交易员、风控和基金经理。基金经理批准之后，订单才会发给模拟交易所执行。 三个地方值得看： 1. 记忆。每次决策都会记进日志，下一次运行时，它会先结算历史决策的实际收益（原始收益和相对基准的 alpha），再写一段反思，基金经理做决定时会读到。 2. 回测。按每个分析日期可获得的数据来做，比如美股财报用 SEC EDGAR，回测时看到的是当天已披露的数字，而不是后来修订过的。这类防止"偷看未来"的细节，很多同类项目都没有认真做。 3. 开箱可用。支持 OpenAI、Claude、Gemini、DeepSeek、Qwen 等多家模型，也能接 Ollama 本地模型。有命令行和 Python 接口，也有 Docker。 要提醒的是，README 自己写明这是研究用途，不是投资建议，结果会受模型、温度、数据质量影响，两次运行也可能不同。小路读的是文档，没有跑过实盘。 简单总结一下就是：它是一个研究多智能体协作的好脚手架，不是一个有固定收益的策略。 GitHub：https://github.com/TauricResearch/TradingAgents 论文：https://arxiv.org/abs/2412.20138

Ethan 恩宇

@UPing123zzz · 2026-10-28

做企业知识库时，我发现一个很常见的倾向。 只要用户说希望能够用自然语言查询公司数据，开发者就立刻想到 RAG、Embedding 和向量数据库。 但企业数据本来就不是同一种东西。 假设员工问今年最新的报销制度是什么，答案可能藏在 PDF 或者内部文档里。这时候使用检索系统寻找有效资料，再根据证据回答，确实很合适。 可如果老板问上个月每家门店的实际销售额是多少，情况就不一样了。 数据可能已经存在业务数据库里，有明确的时间、门店、订单状态和金额字段。 这时候把销售流水导出成文本、切成 Chunk、生成 Embedding，再让模型去猜数字，多少有点舍近求远。 因为很多问题本来就应该通过数据库查询、聚合和明确的计算规则来处理。 向量检索擅长发现语义相关内容，但它不天然保证准确计算、完整枚举或者遵守复杂的业务过滤条件。 如果问题要求精确统计就应该优先考虑结构化数据查询。模型可以帮助理解用户意图、选择查询工具、解释结果，但查询本身需要遵守明确的数据权限和计算规则。 这里还有一个特别重要的点，让模型生成 SQL，也不代表应该直接把它生成的语句拿到生产数据库上执行。 权限、允许访问的表、查询超时、结果大小、只读限制，以及敏感字段控制等等都需要独立设计。 所以我现在觉得企业 AI 应用可能需要多种数据访问能力协作。 文档类问题走 RAG，精确数字查询走数据库，涉及实时状态则调用对应业务接口。一个问题如果同时需要制度和经营数据，就把不同来源的证据分别取回来，再组织答案。 这种架构当然比上传 PDF 做聊天复杂，但它更接近企业真实的数据环境。 很多 AI 项目后期为什么容易出现回答数字错误、资料不一致、业务规则混乱的问题？ 我觉得其中一个原因就是开发者太早选定了向量数据库，然后试图让所有问题都适应这套技术。 模型应该帮助我们更方便地使用数据。但数据本身是什么类型，应该怎样读取和计算，仍然需要程序员认真设计。 如果所有数据最后都变成了向量，可能意味着我们在最开始就丢掉了一些本来非常重要的结构。

Ethan 恩宇

@UPing123zzz · 2026-10-28

前段时间在 GitHub 上研究 PageIndex，这个项目有一个地方让我印象特别深。 现在很多 RAG 教程几乎形成了固定流程：文档切块、生成 Embedding、存进向量数据库、检索 Top-K，再把结果交给大模型。 这套方案确实非常常见，也有大量成熟实现。 但 PageIndex 提供了另一种思路。 它没有把所有检索都建立在向量相似度上，而是尝试保留文档的层级结构，构建树形索引，再让模型沿着文档目录逐步寻找相关内容。 这个思路让我想到一个很实际的场景。 假设有一份几百页的公司年报，里面有目录、章节、表格和大量相似的财务描述。 如果你直接把全部内容切成固定长度的 Chunk，某些片段可能在语义上非常相似，但原本所属的章节、年份和上下文不同。 模型检索到了包含营业收入的片段，却未必检索到了用户真正询问的那个业务部门或者会计期间。 而层级检索可以先定位到相关章节，再继续往下查找具体内容。 这种方式的优势在于它更容易利用文档原本的组织结构，也更方便追踪检索路径。 但我不认为这就意味着向量数据库要被淘汰了。 因为真实企业知识库的资料类型非常复杂，有些是结构清楚的报告，有些是大量短文本、聊天记录、零散 FAQ，还有些来自持续变化的数据源。 树形检索和向量检索适合处理的问题不一定相同。 而且让模型多次判断应该进入哪个节点，也会引入额外的调用成本和延迟。树形索引本身如果生成错误，同样可能把后面的搜索引到错误位置。 所以我现在更想研究的是检索架构如何根据数据结构和问题类型选择。 长篇结构化报告，可以认真测试层级检索；大量碎片化知识，可以比较 BM25、向量检索和混合方案；涉及复杂条件的查询，可能还需要结构化数据库。 真正应该决定技术方案的是文档特点、用户问题和实际评测结果。 以前我学 RAG，容易把向量数据库当成一个必须安装的标准组件。 现在觉得它应该是一种需要经过选择的技术方案。 PageIndex 最值得我学习的地方可能就是提醒开发者重新思考一个问题：我们到底是在寻找语义相似的文本，还是在寻找能够回答问题的正确证据？

How To Prompt

@HowToPrompt__ · 2026-10-27

RAG is officially cooked. IBM built a retriever that hallucinates 65x less than fine-tuned RAG systems. Right now, every company is using Retrieval-Augmented Generation (RAG) to stop their AI from hallucinating. The idea is to give the AI a private database to read so it doesn't make things up. But there is a massive structural flaw. Standard RAG blindly grabs documents based on vector similarity and forces the AI to read them. If the retriever pulls irrelevant garbage, the AI doesn't stop. It just hallucinates with citations. IBM just dropped a paper that changes the math entirely. They built a new retrieval architecture that hallucinates 65x less than state-of-the-art fine-tuned RAG systems. 65x is the difference between a fun prototype and a production-grade enterprise system. Instead of blindly dumping context into the model and hoping for the best, their system actively filters and validates the retrieved data before the generation step even begins. It cuts out the noise. It forces absolute precision. For businesses, this is the holy grail. Zero hallucinations means zero liability. It means autonomous agents can finally be trusted with sensitive company data without a human babysitting every output.

yibie

@yibie · 2026-10-29

RAG 检索不准时，大家第一反应是调切块大小、换 embedding 模型。一个日本工程师的文章说，问题可能出在更底层：把文档切成小块、只按语义相似度找，这件事本身就有结构缺陷。 合同里的「第 3 条例外」、技术文档里的「排障第 5 步」，这类信息必须连着上下文才有意义。一切成块，连续性就断了。而在术语密集的法律、金融、技术文档里，语义相近的词和答案真正写着的位置，经常不是同一个地方。 他介绍的开源项目 PageIndex（2026 年以来多次登上 GitHub Trending）把前提翻了过来：不做向量化，而是从文档的标题结构生成一棵可推理的目录树，让 LLM 像人翻长文档一样检索。 机制分四步。加载文档，抽出章、节、条的层级，变成一棵树。让 LLM 给每个节点写一句该节讲什么的摘要。提问时从根逐层下钻，每层让模型判断「要回答这个问题该读哪个子节点」。定位到末端小节后，取回正文生成答案。 1. 先看目录，猜问题大概在第 4 章。 2. 再看第 4 章的小节标题，继续往下缩。 3. 到末端小节，读正文作答。 副作用也实在：不用再搭和运维 embedding 数据库，索引重建、向量库版本管理、相似度阈值调整这些活都没了。 他拿一份约 80 页、4 级标题的内部业务手册实测。问「退货处理的例外条件」时，传统向量检索好几次命中了含相似词的其他小节；换成目录导航后，一次走对章节的概率明显提高。 但它不是万能的。聊天记录、纯要点笔记这类几乎没有标题结构的文本，根本没有可跟随的树，建目录没有收益。而且每次提问都要多调几次 LLM 来下钻，延迟和成本对实时场景要提前估算。 他第一次实现也失败过：只把标题文字丢给模型，碰到「第 3 章 运营」这种抽象标题，每个章节看起来都可疑，缩不下去。解法是给每个标题补 1–2 句「这一节具体处理什么、谁在什么时候该读」的摘要，并人工核对一遍。自动生成的摘要不能盲信，人工看这一遍反而是最省时间的一步。 小范围验证成本很低：挑一份标题清晰的文档，只抽标题做成层级列表，每个标题配一两句摘要，再准备 5–10 个常见问题，让模型只看目录回答「该打开哪个标题」，和正确章节对一下准确率。准确率低就回去改标题命名或摘要粒度。 我的判断：不必把向量检索和目录导航当成二选一。他实测最顺的配置是两段式——先用目录导航缩到 2–3 个可疑章节，再只在这几章内部跑向量检索。章节级的粗筛交给结构，句级的细匹配仍交给向量，准确性和速度都比把所有文档塞进一个巨型向量空间好。对已经有 RAG 的团队，这意味着不用推倒重来，只要在现有检索前加一层目录预筛，改动最小。 引入前他给了四条自查：文档至少有章、节两级标题；每章文本量在 LLM 一次读得下的范围内；单次提问多几次模型调用的成本和延迟可以接受；能先从 5–10 题的小验证做起而不是直接废掉现有向量检索。四条都满足就值得试；如果文档本来就没什么标题，继续打磨向量检索反而是更短的路。 原文链接在评论区 #RAG #LLM #信息检索

Ethan 恩宇

@UPing123zzz · 2026-10-29

很多程序员有一个挺大的问题就是明明自己技术不差，项目也做过不少，甚至在公司里承担着很重要的工作，但在外部市场上，几乎没有人知道他是谁。 每天写代码、修 Bug、做需求、赶项目，忙得要死。几年下来，代码写了几十万行，系统维护了好几个，技术水平确实提高了，但所有的成果基本都留在公司内部。 一旦哪天离职，或者公司业务调整，突然发现自己除了简历上的几段工作经历，根本拿不出多少能向外界证明自己能力的东西。 我觉得这其实挺可惜的。尤其是在 AI 时代，技术变化这么快，岗位和公司的稳定性很难由个人决定。如果一个程序员的全部价值都需要通过某家公司来证明，那他的职业选择其实是比较被动的。 技术人一定要尽早建立自己的个人 IP。 但我说的个人 IP，不是让所有程序员都跑去当自媒体，也不是让你天天研究流量密码、做知识付费、卖课程，更不是让你为了涨粉去制造一些自己都不相信的观点。 而是你要有意识地把自己的能力变成可以被外部世界看见的东西。 你做过什么项目，解决过什么技术难题，为什么选择某种架构，踩过哪些坑，最后又是怎么解决的，这些其实都是非常有价值的内容。 比如我最近在做一些企业 AI 项目，接触到 RAG、Agent、数字人和自动化工作流，慢慢发现真正的工程问题和网上那些几分钟搭建一个 AI 产品的教程，完全不是一回事。 一个项目从最开始的需求沟通，到 API 对接、系统设计、开发测试，再到最后的交付，里面有大量细节是教程根本不会告诉你的。 这些真实的经验，如果只是做完就结束了，其实特别浪费。 你完全可以把它整理成技术文章，写成项目复盘，把不涉及客户机密的代码和工具开源出来，放在 GitHub 上，再通过 X 分享出去。 今天可能只有几十个人看，明天可能只有几百个人看，但只要内容有价值，你就在慢慢积累属于自己的公开作品和行业信誉。 时间长了就可能有人因为你的文章关注你，有人因为你的项目找到你，也可能有招聘者、创业者或者潜在客户，通过你过去的内容判断你是否适合合作。 我觉得这种机会比单纯追求粉丝数量更重要。 一个只有几千粉丝的技术账号，如果关注者里有大量开发者、企业负责人和真正有需求的人，它带来的机会未必比一个几十万粉丝的泛流量账号少。 当然，个人 IP 也不是万能的。你有粉丝，不代表你一定能赚钱；你有流量，也不代表有人愿意付钱。更不意味着你可以不提高技术能力，直接靠营销吃饭。 真正有价值的个人品牌，必须建立在真实的能力和长期积累的信任上。 而且我觉得，技术人还有一个很大的优势，就是你不需要凭空制造内容。你每天做的项目、遇到的问题、做出的技术取舍，本身就是内容来源。 代码可以放 GitHub，作品可以放个人网站，思考和经验可以发到 X，客户案例可以在获得许可后整理成公开材料。 这些东西积累三五年，留下来的可能就不只是一份简历，而是一整套能够证明你专业能力的作品。 现在我越来越不想把自己未来的所有机会，都寄托在某一家公司愿不愿意录用我、给我多少钱上。 我还是会认真工作，认真学技术，但与此同时，我也希望让更多人知道我到底在做什么、能解决什么问题。 因为公司可以决定给不给你一个岗位，但不应该由一家公司来决定整个市场是否看得见你的能力。 对技术人来说，最值得长期经营的资产之一，就是自己在行业里的信誉和被选择的机会。

Ethan 恩宇

@UPing123zzz · 2026-10-29

我发现很多程序员，包括我自己在内，其实特别容易陷入一种技术自嗨。 今天研究一个新的 Agent 框架，明天研究 RAG，后天又去折腾 Skill、MCP、各种自动化工作流。每天都在 GitHub 上看项目，都在研究最新的模型，感觉自己学到了很多东西，技术能力也确实在进步，但你要问这些东西到底解决了谁的问题，有没有真实用户，有没有人愿意付费，很多时候自己都说不明白。 尤其是现在 AI 编程越来越强，很多以前需要花不少时间才能开发的功能，现在借助 Codex 就能很快搭出来。一个人做个网站、做个 Agent、做套自动化系统，门槛确实比以前低了不少。 但问题来了，当越来越多人都有能力做出类似的产品时，你凭什么认为自己的东西就有人买？技术实现只是一个环节，真正困难的可能是找到需求、建立信任、控制成本，以及让客户持续获得价值。 我现在在企业里做 AI 落地，接触过 GEO、RAG、Agent 和 AI 视频生成之后，对这一点感触越来越深。比如一个数字人视频生成项目，API 已经调通了，视频也成功生成了，从程序员的角度来看，这似乎已经完成了。 但如果客户要求的字幕、包装、画面质量都没有达到标准，这个项目实际上还是没法交付。你不能跟客户说我的接口返回成功了，所以你应该满意。人家买的不是一个成功的 HTTP 响应，而是一个真正能解决业务问题的结果。 技术人真的应该多学一点商业、产品、用户心理和沟通。你能写出代码，是技术能力；你能让别人愿意使用，是产品能力；你能找到客户、理解需求、完成交付并获得收入，那才是真正的商业能力。 而且我觉得最可怕的不是你技术不够强，而是你花了很多年把技术练得特别厉害，却从来没有认真研究过自己的能力到底怎么创造价值。 技术当然要学深，但千万别把技术本身当成了最终目的。

Viking

@vikingmute · 2026-10-29

虽然现在不怎么看代码了，但是这条关于 React 的很受用啊，尤其是 AI 时代。 极端一点可以让 AI 在 React 中禁止使用 useState，因为我见过太多 AI 直接往里面怼超多的本地 state，同步容易翻车，或者漏掉相关状态的处理。 简单开关可以用，复杂本地状态直接使用 useReducer 进行替换，所有变更都用 dispatch 进行处理，并且配备对应的 lint。 原帖的讨论也很好，里面有很多 insight。

山景城小路

@Zen_with_AI · 2026-10-28

hyperframe studio我也试了，确实是做youtube的博主必备。 https://hyperframes.studio/ 视频生成已经从镜头转到芯片上了。 另外他们家的 claude/codex plugin. skills 也建议装上。 写 HTML 就能渲染成视频。