你的应用在模型公司的打击范围之内吗？
（这一节与技术无关，可跳过）
我们先要讨论应不应该做，再来讨论怎么做。
”AI应用市场的模型公司”和”传统应用市场中的大公司“的地位不太一样。在传统应用中，确实有小公司打败大公司的，大公司对小公司的优势可能是规模效应优势（凭借自身流量大的平台比如X信）、营销优势，不一定有技术优势、运营优势；但是AI应用开发，模型的能力是最最最基本的东西，模型一次升级就有可能干碎几个月应用层的努力，没AI你这个应用就压根做不出来（或者效果不好，达不到用户愿意使用的阈值），谈运营有啥用？模型公司可以给你分分钟断供，Anthropic就给windsurf断供过。
模型公司的应用开发团队能得到来自模型团队的支持，模型在他们眼中不是完全的黑盒，比如Anthropic就有在做一些解释性的工作，他们发现LLM给人类展示的解题过程和它真实的解题过程未必一致。OpenAI的deepresearch是经过专门后训练的，效果就是比那些只在应用层优化的应用要好。
只在应用层做优化，极难对模型公司的应用产生显著优势，再加上模型公司自己的产品可以开出更低的价格，那用户凭什么用你的产品？现在codex,claude code盖过了cursor等产品，就能证明这一点
如果在打击范围之内，那么在模型公司出手之前，可以赚一段时间的钱。比如之前的cursor是一扫所有竞争对手的。
人类的心理缺点
人类经常认为复杂的、不好理解的就是厉害的，简单的就是低级的、偷懒的。培训班就喜欢利用这个来骗人
RAG(embedding模型)被滥用了
embedding只是个不太靠谱的语义搜索工具，如果你根据直觉，感觉这个任务不是语义搜索这么简单的，需要一些思考的，那还是要用gemini这种长上下文模型。
为了解决embedding模型一次性输入长度不足的问题，你不得不用各种复杂手段来给它打补丁。
现有的 gemini flash lite 的上下文长度已经有100万了，足够应对大部分文档检索问题，而且gemini也推出了上下文缓存功能了，这样长远来看是比embedding更贵，但是检索效果和工程师的时间成本都更好，用户想要更好的效果，那就应该为此多付钱，走高端路线，可以开更高的价格，利润更高。
假如资料有3千万token怎么办？给资料做分类，每个分类80万token以内（这只是个估测值，llm的实际可用token窗口比纸面会低，超过某个阈值，智商会显著下降）
假如你用的是embedding模型，一次才能装3000token，那至少要切1万次，让人工来做恐怕不太可能，那只能暴力切分，然后在切分边缘保留一些重复内容。
这里会放一些大部分人都知道的，当做检查清单
大部分资料至少还能精简50%以上。《重来》三部曲是我见过的少有的极其精简的书籍，我划线标注的时候，往往都是划整个章节的内容。作者写这本书的时候，把草稿的字数精简了一半。Naval说推特的140字符限制能让你更加懂得精简表达，我自己实践后发现也的确如此，尝试几轮后总是能把文字精简到140字符内
我听到的另一个很有意思的角度是：你是在用一个低端模型给高端模型提供数据，上限直接被这个低端模型限制了
不要用LangChain
Anthropic的文章讲过这个，这是人家和十几个团队总结出的经验。培训班整天鼓吹这个框架，就因为这个框架比较复杂，需要很多天才能学会，这样就显得整个课程很有分量。换句话说，请思考一下，培训班做ai应用的经验丰富？还是anthropic做ai应用的经验丰富？
当你创建了一个工具，然后又拉了投资，为了向投资人交差，以及让雇佣的一堆人有活干，方法之一就是搞一个工作量大的东西。
Agno、LangGraph好一些，小的agent可以用这个。
“他们都没有用我的这个方法”
你不能假定那些行业领先者用的技术就是最好的。凭什么我就不能是找到最好的方法的那个人？（详见彼得蒂尔的《从零到一》）
24年，那会cursor是最厉害的AI编程工具，那时我自己就开始让AI在写代码前先让它制定一个计划了。如果plan mode这么好，为什么cursor当时没做？不知为何，cursor就是没做，直到claude code出来之后，大家才普遍认识了plan mode
那时候我也在想是不是可以试试todo list，有时候要做的事情真的很多，过程很长，AI真能记住所有要做的事情吗？有时候的确如此，有时候不是这样。遗憾的是当时我没有意识到“与AI这种不确定的东西交互，必须要像爱迪生一样试验各种可能”，就没有去尝试。
输出长度、上下文容量不等于注意力分配能力（智力）
gemini2.5的输出token6万，之前尝试让llm翻译一个1万token的html都会出错
思考的负面作用
在英文翻译到中文上，gemini 2.5全系列，思考完全关注错了重点。如果llm本身没有经过对应的训练，思考完全没用。让豆包来翻译，自动触发的深度思考很有用，能准确地为难点分配更多的token
在视频转成截图文字稿的应用上，有一个实现方式，2.5pro被2.5flash吊打
CoT变体
跟chain-of-thoughts的思想是一样的，你要让llm展示出思考过程（尽管anthropic的研究显示它展示给人类的思考过程和它内部的思考过程并不一致），这样就会迫使它给一个问题分配更多的token
如果你的应用不需要cot，但是你的应用可能需要让llm输出它做的种种判断，
一个简化的例子是，假设你要让llm做文本分类任务（现在的llm肯定可以把它做得很好，这里只是做简化，你可以换成一个对现在llm来说很难的分类任务）
你不能只是说”输出这个文本的分类，是正面、中性还是负面“，你还要说”为什么这个文本被分类成正面、中性、负面”，这就会让llm分配更多的token在上面
这个方法在我之前的应用中效果约等于0，但是在我的另一款应用中工作得相当好，我之前完全没想到有这么好的效果
这么做的另外一个好处是便于debug，能看出是你指令写得有问题，还是LLM本身能力不行
模型似乎没有能力？把所有可能的情况的例子发给AI
在video2screenshottranscripts.com中，有一个环节，我让o3（当时还没有gpt5）和gemini2.5pro去解决，一开始因为认为他们很聪明，能够解决这个问题，结果发现思考了100多秒还是不能，加了点例子，还是不行。过了一小时，我觉得还是可以再加一些例子，我把所有可能的情况的例子都给了AI，最终成功了。
爱迪生
根据前面的内容，我们可以得出结论：你要像爱迪生一样，实验所有的可能。
llm仍然是个黑盒，只能尝试各种可能的办法，才能说你找到了最佳的方法。
直接问模型，为什么它误解了你的意思
比如你在提示词里教它要怎么做，你觉得你已经写得够清楚了，结果它理解成了另外一个意思，你告诉它哪里理解错了，然后问他我的提示词应该怎么写，才不会让它误会。
这个方法同样可以用于调试Claude Code里面的定制提示词
大模型到底能不能按你预想的方式工作？
一句显而易见但是重要的废话：设计完成后，先试试大模型到底能不能按照你预想的方式工作，不需要写代码，直接人肉模拟代码调用大模型就行。你的应用层代码是和大模型的行为绑定的，如果大模型不能按照预期的方式工作，那么你只能更改代码，或者换个更合适的模型。
为什么容易犯这样的错误？设计一个传统应用的时候，某个模块能不能实现我们心里都有数，能写出伪代码，不会出现“其他模块写完了，结果发现最后一个模块你没法实现”的情况。对于大模型，很容易想当然地认为它能够按照你预期的方式工作，认为这个伪代码可以跑，它到底能不能？只能去试。
试10次，大模型能够成功8次吗？出错的那2次会严重影响应用吗？出错的那2次可以用代码或者让另外一个LLM来检测、修复吗？
不同模型用不同的工作流
不同模型未必能套用同一个工作流
之前cursor接入sonnet 3.7的时候，sonnet3.7表现得不遵守指令
我们是基于模型的能力来开发的，模型的优缺点不一样，所以对每个模型都用同样的流程，效果可能不会好
system prompt适合写总体指导，user prompt适合写大量具体例子
这点anthropic讲过，我补充一下如果不这么做会怎样：有可能会导致AI在后续对话中出现幻觉。2024年底我开始用gemini 2模型（因为上下文窗口大），我把3个翻译html的例子写在了system prompt里面，然后我把一个长html内容拆出来分几次发给gemini，结果最后gemini没有输出我给它的长html，而是输出了我在system prompt中的例子的翻译
非技术向防止提示词泄露
金丝雀词汇、专门安排一个模型检查攻击这些老生常谈就不说了。
最治本的方法是检测到后，给一个假的，但是要足够逼真的提示词。攻击者以为套到了，就不会再攻击了。
“在xx情况下你要用xx工具”，但其实你根本没用这个工具
并行运行10个llm，然后投票，但最佳答案未必是其中一个
最好的答案可能是这从这个llm中取一部分，另外一个llm取一部分
Bootstrap 统计法
用来测试AI应用对输入是否敏感
比如你有100个测试用例，你要有放回地从中拿100个到一个盒子里，这样一个测试用例可能会被抽中多次。重复这个过程，你得到10个盒子，然后运行这10个盒子的测试，如果这10个分数差距很大，说明AI应用对数据敏感。
AI的信心有多大？
看Logprobs，这个代表了token的概率。概率大就表明AI在训练资料里面见过这个。
改进后要再添加测试用例
你做了点改进，AI应用的分数高了1%，你怎么知道这不是运气？
变化越大越容易看出来，变化越小，就需要更多的数据来证明这不是运气
OpenAI 给的建议是:
| 改进幅度 | 需要添加的用例数量 |
|---|---|
| 30% | 10 |
| 10% | 100 |
| 3% | 1000 |
| 1% | 10000 |
尽可能结构化
你可以用A,B,C 这种纯文本的形式来输出列表，但最好还是用json输出，会明显地更稳定
Agent
先制定一个计划、todo list、skill这种老生常谈不说了
Subagent
和使用AI编程工具中的subagent类似，如果你只需要最后的结果，中间的过程不重要，那么把这个任务派给subagent就行了
自我压缩上下文
和subagent思维类似，如果你只需要结果，不需要过程，那就可以把过程从上下文中删除，但是要注意，如果过程中有犯错，要把错误保留下来，防止AI将来犯同样的错误，详见Manus的agent文章，这里犯错过程大概率是可以压缩的
资料推荐
www.anthropic.com/engineering…
www.anthropic.com/engineering…
platform.openai.com/docs/guides…
其他
AI应用的真正转折点是2024年6月份，Anthropic推出Sonnet 3.5，他那个之前ai只能做很简单的应用，我看了一圈，有些岗位居然要求2-3年Agent经验
