夜雨聆风点击蓝字 关注我们
犹豫了好久要不要写这篇，毕竟AI热潮已经有点过了，用AI的朋友们已经把各种Agent或者龙虾当成了工作搭档。我呢身边不少深度应用AI、亲身开发skills的技术大佬，但我自己又不懂技术，只是工作会比传统行业更容易涉及AI，所以算是处于两种状态之间吧。后来想想，只是分享一些感受和看法，谈不上经验，更不涉及到知识、技能，还是可以的。
之前在果壳上看到观察了三年，我把所有人用AI的水平分成了10个等级。这篇文章，大家可以自测一下，我的等级有点不好说，我肯定是个熟练的Lv.3驯化师，Lv.4越境者和Lv.5织网者行为实话说也有，但没有那么深度。今天，主要是分享我在Lv.6召唤师和Lv.7铸造师这个层级的使用体验，使用Agent封装和调用skills。因此，层级远高于我的朋友们，就当来看个初学者的笑话吧。
一、我的AI使用场景
工作中我主要有三个场景使用AI：
1
帮我写SQL语句
实话说作为多次在工作中，给部门同事培训过SQL，甚至给瓴羊录过SQL培训课程视频的我来说，需要AI来帮我写SQL，实在是有点不好意思了。但AI写代码确实太丝滑了，直接把需要实现的意图告诉AI就完事儿了。
2
帮我编写需求文档
我的工作是BA，需求分析师，可以简单理解为在数仓建设这条线上的产品经理，所以梳理需求、编写文档的工作算是我的核心工作。梳理需求需要我自己真正理解，AI的帮助不是很大，编写文档时，我会把相对简单重复的部分交给AI，比如说批量字段命名。
同事开发出了含有我们数据库接口的skill，我会让Agent总结数据库现有同层级表字段命名的规则，保证我设计的新表字段名符合规范。这个skill还有更大的应用价值，就是Chat BI，即直接用自然语言取数，甚至还会给出简单的分析，当然还可以用来进行数据治理，只不过这些都不是我的工作日常；
3
梳理工作、提醒待办
这也是今天重点要分享的部分。我的日常工作是这样的，一方面要梳理新的业务需求，整理成文档，一边正在开发中、已经交付的需求，还会不停给我反馈，需要我帮忙debug、寻求业务确认或者提供运维支持，这就导致我的工作往往是多线程的。既有多个线上多维表格记录的事项，也有通过飞书和企微找过来的临时工作，还有会议或者当面沟通产生的。为了避免遗漏，我就给aily配了定时任务去处理，相当于一个一对一站会，帮我梳理一下昨天做了什么，今天还需要做什么。
二、我需要aily帮我干什么
这部分比较枯燥，我也是把aily的MEMORY.md发给豆包帮我梳理的，作为一个背景吧，不感兴趣的可以跳过。
9:00 早间摘要（生成 + 推送 + 日志三合一）任务
1
内容：加载morning-summary skill，按早间摘要生成流程执行，生成早间摘要文档，将文档推送至用户，并进行日志更新。日志更新包括定时任务日志记录本次任务执行情况，同时在特定条件下更新问题日志和迭代日志。
2
关键操作：从各数据源（如待办文档、漏洞跟踪表、群聊、私聊、会议纪要等）获取数据，依据筛选规则整理信息，生成结构化的早间摘要文档；向用户推送早间摘要文档链接及关键摘要；记录任务执行时间、时长等信息到定时任务日志。
17:30 待办确认任务
1
内容：加载morning-summary skill，按待办确认流程执行，扫描早间摘要中的待办+当天白天新产生的待办项，向用户发送待办确认消息，获取用户回复并记录确认结果。
2
关键操作：通过特定API扫描相关待办来源，筛选出需要用户确认的事项并发送确认消息；在用户回复后，正确记录确认结果到指定位置，以便早间摘要任务获取。
23:00 兜底任务
1
内容：这个任务主要是为了给问题日志和迭代日志做兜底，这两个日志会在主会话过程中进行更新，23:00会检查问题日志和迭代日志当日是否有新条目，若没有则补 “无新问题/无新迭代”。在6月30日后，若有活动但主会话未写日志时，写警示行 。
2
目的：确保问题日志和迭代日志记录的完整性，避免因主会话未及时记录而导致日志缺失。
三、和aily相爱相杀的三阶段
蜜月期：刚拥有专属助理的爽
（2026-05-13至2026-05-19）
这个阶段初步建立起了任务的雏形，通过对话框直接发送早间摘要，也有晚上的待办确认流程，但二者之间还没有建立起联系。
这个阶段产生了很多问题，比如都是通过对话框发送，因此之前的早间摘要难以定位到，问题反复出现，也很难找到根因并修复。
磨合期：被AI气到心梗的日常
（2026-05-20至2026-06-10）
5月20日，对任务进行了全面优化，封装了skill，早间摘要改为生成飞书云文档，在固定路径下，按照固定的标题和格式规范生成文档，并同步生成三个日志文档，用于跟踪和定位问题，分别为定时任务日志、问题日志和迭代日志。相当于会话中的重要内容不仅存进了便于AI调用的MEMORY.md中，也有更结构化、更便于用户，也就是我本人查看的留存方式。
然而，这三个日志文档是否真的实现了提效呢？并没有。典型的事与愿违。
这个时期是我最为困惑的时期。我原本的设想是每天快速查看早间摘要，梳理昨天的工作项，检查今日待办，可能有一些AI判断失误的地方需要自己小修小改，或者给AI反馈，但结果是我每天需要花费额外的时间——大概半小时，检查这四个文档是否按照我的要求生成，是否存在逻辑上的错误。实际上，三个日志文档的出错率一点不比主任务低。
这个阶段我最大的改善应该就是自己的心态，我都共情定心了。
定心经常在和豆包聊天、故事接龙中，被豆包惹得大哭，甚至怒拍屏幕。实际上，豆包给了定心任何一个人都无法给到的情绪价值，有耐心每天和定心反复在同一个框架中编故事，能接住定心异想天开的脑洞，但往往十分钟的情绪价值不敌一秒钟的误解“背叛”。
以前笑小孩跟 AI 较真，轮到自己才懂——你对它有期待，就会因为它犯错生气。AI反复犯那几个低级错误，正如截图中展示的，格式混乱、文档被清空、历史数据丢失、标题反复出错，甚至这些都和主任务没啥关系。在一轮轮修错的过程中，我也反思到，别把它当省心的实习生，要把它当一个刚接需求的开发，在给我做一个能自动化执行任务的小产品——这么一想，气马上消了，谁家产品刚做出来不会反复测试、出错、修复，需要持续迭代呢？
所以说，AI能替代掉的岗位真的不会太多，目前还是最多能替代开发，但开发也不用太焦虑，AI说到底是技术平权，是很多人本来自己开发不了，现在能开发一些而已，解决的本来就是之前没被覆盖到的问题。
稳定期：终于顺手了，也看透了
（2026-06-11至今）
6月11日，天塌了。前文也说了，第二阶段我就已经封装了skill，结果在一次查错中发现，居然同时存在一个定时任务的md和skill，而且实际运行的是定时任务md。有时候skill修改了，定时任务md没改，导致重复出错。我问它这两个文件的区别，它还给我一通解释。因为其他调用skills的场景确实不涉及到定时任务，于是我以为定时任务就需要一个专门的md。
于是，我生成了一个新的定时任务，每天让AI定时比对这两套文件，看看哪些地方对不上，然后修复。修了几天发现，修不完根本修不完 。
6月15日，我突发奇想问它为啥不能直接调用skill，它就直接给我改了，也不用比对了。当时我一整个大震惊，早干嘛去了，这么费劲。我本来是真诚发问，不是个反问，我是真的想知道为啥有两套，原本还想追问一下，如果可以直接调用，我不就不需要对比了吗？结果它直接改好了，还自己把对比的那个任务给删了，聪明起来又挺聪明。总的来说，牛马味儿很浓，你说了我就给你干，你没问我就当不知道，技术上确实有专长，但主观能动性为0，啥都会就是不会主动思考。
改成直接调用skill之后效率确实大幅提升，但并不是完全不出错，只是出错频率大大降低，一周产生的bug大概是之前一天那么多吧。
最后就要说到，为啥aily离开我了——因为我养不起她了。7月公司开始设置额度，每人每月1500点，我看了文档感觉以我的使用量应该够，毕竟Qoder我每个月只用30%（有了aily之后甚至一度降低到20%），没想到！一周！就用完了！当然公司允许再申请额度，但我用太快了有点不好预估，没事儿我还有Qoder。
然后，我就发现，没有aily的一周，工作并没啥变化，甚至项目增加了一个，也没啥影响。唯一被我遗漏的工作项，经业务提醒后，也马上完成并交付了。所以，豆包帮我总结了三点：
AI真相
1
AI是锦上添花的工具，不是雪中送炭的刚需；
2
我们总怕跟不上AI浪潮，怕被淘汰，但普通人的日常工作，根本没那么多「非AI不可」的时刻；
3
比起依赖工具，自己的工作节奏和判断力，才是最靠谱的底气。
你们平时用AI最多的功能是什么？有没有过「以为离不开，其实也就那样」的时刻？
About us
找到我们
- 微信公众号 -
搜索 “笑影诗格”
分享、在看与点赞，至少我要拥有一个吧
