夜雨聆风很多人第一次搭 AI 助手，都会从 prompt 开始。
这很自然。因为 prompt 最容易改，也最容易让人产生“我在调教 AI”的感觉：换一个角色设定，加几条规则，补一个输出格式，模型马上就能给出一段看起来更顺的回答。
但真把 AI 助手放到每天要用的工作流里，问题很快就变了：
它不是不会回答，而是不会自己开始。
它不会自己知道今天该抓哪批新闻，不会自己知道昨天公众号任务为什么没跑完，不会自己判断哪些快讯该入库、哪些只是网页噪声。它也不会天然知道什么时候该提醒人，什么时候该安静。
所以我养了一段时间“龙虾”之后，越来越觉得：长期 AI 助手真正难的不是 prompt，而是让它每天醒来，按时干正事。
一次性聊天很容易。长期工作流很难。
你今天让它总结一篇文章，它能总结；明天让它查一只股票，它也能查；后天让它写一篇公众号，它还能写。但如果每次都要人重新打开聊天框、重新交代背景、重新提醒边界、重新保存结果，那它本质上还是一个“问答工具”，不是一个“助手”。
我想要的龙虾不是这样。
我希望它能像一个小小的工作流系统：每天有固定的任务，有输入，有输出，有失败记录，有复盘，也有权限边界。
这篇就讲这件事。
1. prompt 解决的是“这一次怎么答”，工作流解决的是“每天怎么干”
prompt 很重要，但它解决的通常是单次交互问题。
比如：
- ● 这篇文章要写得更像公众号；
- ● 这个股票分析要分成基本面、资金面、消息面；
- ● 这份报告要先给结论，再给证据；
- ● 回复要短一点，不要废话。
这些都是必要的。
但一个长期 AI 助手要面对的是另一类问题：
- ● 它什么时候启动？
- ● 去哪里拿数据？
- ● 拿不到数据怎么办？
- ● 哪些信息要入库？
- ● 哪些信息必须二次核验？
- ● 什么时候提醒人？
- ● 什么时候保持安静？
- ● 失败了要不要保留旧结果？
- ● 第二天怎么知道昨天哪里坏了？
这些问题，单靠 prompt 很难解决。
所以我后来把“养龙虾”的重点，从“写更好的 prompt”，逐步转向“搭更可靠的工作流”。
2. 我希望龙虾每天醒来做什么
现在龙虾的任务大概分几类。
第一类是信息采集。
它需要抓市场新闻、金十快讯、行业文章、公告、论文候选、公众号参考文章。这里最重要的不是“总结得多漂亮”，而是不要漏掉关键事实，也不要把脏数据当新闻。
比如金十 live 这类网页信息，如果解析不好，很容易把整个页面的导航、广告、多个新闻块混在一起入库。看上去库里有很多“新闻”，但实际上很多是网页噪声。这样的自动化越勤奋，后面越容易污染判断。
第二类是整理和归档。
信息抓到之后，要按主题放好：AI 算力、半导体、光通信、存储、商品、宏观、持仓相关、论文候选、公众号素材。一个长期系统最怕资料散在聊天记录里。聊天记录是流，文件和数据库才是长期记忆。
第三类是低频判断。
不是每条行情、每条新闻都要让大模型思考。高频任务尽量脚本化，只有在关键节点才让模型读快照、读新闻、做解释。否则 token 会被无意义消耗掉，而且模型还会被碎片噪声带偏。
第四类是内容生产。
每天读一篇论文，生成公众号草稿；隔几天写一篇“养龙虾手记”；把市场和工程经验沉淀成文章。这里模型很有用，但前提是素材干净、结构清楚、事实可追溯。
第五类是自检。
任务没跑、脚本报错、token 不够、数据源异常、文章没生成，这些都应该被记录下来。一个助手如果只会成功时汇报，不会失败时留痕，那就不可靠。
3. “每天醒来”背后其实是四层东西
让 AI 助手每天干活，不是设置一个定时器那么简单。
我现在更愿意把它拆成四层。
第一层：触发层
也就是它什么时候醒来。
有些任务适合 cron：比如凌晨跑自迭代，早上发报告，定时抓取新闻。它们不需要人当场参与，适合独立运行。
有些任务适合 heartbeat：比如顺手检查一下有没有失败任务、最近有没有重要提醒、要不要做记忆整理。它们可以和对话上下文结合，频率不用特别精确。
触发层最容易被低估。没有稳定触发，再好的 prompt 都只是手动工具。
第二层：数据层
AI 助手必须知道从哪里拿东西。
论文来自 arXiv、HTML、PDF、本地 paper.txt；新闻来自金十、市场资讯、公众号文章；股票来自行情、公告、资金、持仓；文章素材来自历史草稿、选题库、模板。
这里的关键不是“数据越多越好”，而是每个数据源都要有基本的可信度标记。
比如：
- ● 官方公告可信度高；
- ● 金十快讯可作为线索，但重要内容仍需核验；
- ● 公众号纪要要标记为待验证；
- ● 用户转发截图不能直接当事实；
- ● 网页解析结果要防止把导航和广告混进正文。
数据层不干净，后面的 AI 判断就会越来越像“自动化幻觉”。
第三层：执行层
执行层决定哪些事用脚本，哪些事用模型。
我现在的原则是：
- ● 确定性、高频、可验证的任务，用脚本；
- ● 需要理解、取舍、归纳、写作的任务，用模型；
- ● 高风险、外部发布、真实交易、不可逆操作，必须人确认。
这条原则帮我省了很多 token，也减少了很多不必要的模型参与。
比如盘中每 5 分钟刷新行情，不应该每次都问大模型“怎么看”。脚本先做快照、阈值判断、异常检测；只有在 09:30、10:30、14:30 这类关键节点，才让模型读新闻、持仓和资金变化，输出策略建议。
AI 系统不是每一步都要用 AI。
第四层：记忆和复盘层
长期助手必须会留下痕迹。
它今天抓到了什么？写了什么？失败在哪里？哪些事实已经核验？哪些只是线索？哪些任务明天要补？这些都不能只存在“脑子里”。
我现在越来越重视文件化：
- ● daily 目录放每天的公众号素材和草稿；
- ● news-engine 放新闻原始数据和信号；
- ● memory 记录重要事件；
- ● docx-validation 记录文章校验结果；
- ● collect-status 记录任务是否跑成功。
这套东西看起来笨，但它让龙虾变得可复盘。
我现在会把龙虾的工作流想成一条很朴素的链路：
触发任务 → 读取数据 → 脚本先清洗 → 模型再判断 → 写入文件/数据库 → 生成报告/草稿 → 校验 → 留痕。
这条链路里的每一步都不神奇，但每一步都决定了它第二天还能不能继续工作。
4. 一个真实的小坑：任务没跑，不能只怪 token
昨天有个很典型的问题：公众号任务没有正常生成。
表面原因是 token 不够，任务没跑完。但继续往下看，会发现系统里还有另一个问题：某个采集脚本在 Node 18 环境下调用了 node:sqlite，而这个内置模块需要更高版本 Node，于是 2026-05-30 的 collect 直接失败。
这件事给我的提醒是：长期 AI 工作流的失败，往往不是一个点。
它可能同时包括：
- ● 模型额度不够；
- ● 运行环境版本不对；
- ● 脚本没有降级路径；
- ● 失败后没有自动补跑；
- ● 前端看板只显示“没内容”，不解释为什么没内容。
如果只是写一句“昨天 token 没了”，问题不会真正解决。一个可靠的龙虾应该把失败原因拆开：额度问题归额度，环境问题归环境，脚本兼容归脚本兼容，补跑机制归补跑机制。
这也是我说的：养 AI 助手不是调一个聪明回答，而是在养一套会暴露问题、记录问题、修复问题的系统。
5. 我现在给龙虾定的几条纪律
第一，能查文件就不靠记忆。
AI 很容易凭印象说“应该是这样”。但长期系统不能靠“应该”。能读状态文件，就读状态文件；能查日志，就查日志；能跑校验，就跑校验。
第二，能脚本化就不要大模型硬跑。
大模型适合解释和生成，不适合做所有重复劳动。高频行情、文件扫描、格式转换、状态检测，都应该尽量脚本化。
第三，重要信息要保留原始字段。
比如新闻至少要有时间、标题、正文。不要只留一句模型摘要。摘要可以后生成，原始字段丢了就很难补。
第四，外部动作必须有边界。
发公众号、发消息、真实下单、操作第三方平台，都不是“助手觉得可以”就能做的事。AI 可以准备草稿，但最后发布必须人确认。
第五，失败要留下证据。
失败不可怕，静默失败才可怕。任务没跑，要有日志；抓取失败，要有 error；数据源异常，要保留旧 latest，不要用空结果覆盖。
6. 以后我判断一个 AI 助手好不好，会看三件事
第一，它能不能持续工作。
不是今天回答得多漂亮，而是连续一周、一个月后，它是否还能稳定产出，是否知道自己每天该做什么。
第二，它能不能少污染数据。
自动化系统最危险的不是没数据，而是把脏数据批量写入长期记忆。新闻库、股票池、论文库都一样，宁可少一点，也要字段清楚、来源明确。
第三，它能不能被复盘。
一个助手给了建议，后来错了，能不能追溯当时基于哪些新闻、哪些数据、哪些假设？如果不能，它就只是一个会说话的黑箱。
7. 结语：让 AI 每天醒来，比让它某次惊艳更重要
我现在越来越不追求“某一次 AI 回答惊艳”。
惊艳很容易截图传播，但真正能改变工作方式的，是它每天按时醒来，做那些重复、琐碎、但长期有价值的事。
抓新闻，清洗字段，读论文，生成草稿，校验格式，记录失败，第二天继续改。
这些事听起来不性感，却是个人 AI 系统真正长出来的地方。
所以养龙虾的第二步，我想先记住这句话：
prompt 让 AI 会说话，工作流让 AI 会干活。
后面我会继续把这只龙虾怎么接数据源、怎么做 skill、怎么省 token、怎么做新闻核验和公众号自动化，一篇篇拆开写。
如果你也在尝试把 AI 从聊天框变成长期在线的工作流，欢迎继续关注「养龙虾手记」。
下一篇我准备继续写一个更具体的问题：别只给 AI 写 prompt，给它做 skill：我的龙虾为什么越来越能干。
如果你也在尝试把 AI 从聊天框变成长期在线的工作流，欢迎继续关注「养龙虾手记」。
