- 博客(23)
- 收藏
- 关注
RSS订阅原创 原生APP还是H5？我做了个报价器
我的结论：上门维修报价器如果主要给销售在微信里用，先做H5更划算；需要离线拍照、持续定位或系统通知，再考虑原生APP。端型选错，后面每个小改动都要多付成本。我用同一份需求做过两个可点版本，最后留下了H5。原生APP和H5怎么选、AI生成APP、维修报价器、说中文做应用、快速原型。
2026-07-29 14:45:37
231
原创 AI生成外勤签到，定位功能怎么补
中描述：“我没有编程经验，请用AI生成一个能用的微信小程序，包含任务列表、到场签到、离场签退和记录页，定位失败要分原因提示。我排障时沿着数据流倒查：页面有没有发起请求，系统有没有给权限，坐标是否带合理精度，距离计算采用的坐标系是否一致，上传是否成功，服务端是否去重，地图展示有没有乱序。围栏越严，定位漂移带来的误判越多。我画的主流程很短，一共七步：开始任务 → 检查授权与系统定位 → 获取坐标和精度 → 判断是否落在签到范围 → 上传时间、坐标、精度 → 现场处理后再次定位 → 结束任务。
2026-07-25 17:58:17
217
原创 零代码做失物招领APP，我改了4轮需求
我的结论先说：零代码做失物招领 APP，第一版出得快，真正影响答辩质量的是后面四轮需求修正。我不会编程，只靠中文描述让 AI 生成了一个可安装、可录入数据的校园失物招领原生 APP；我没有停在“页面能点”，而是把认领、隐私和审核逐轮补齐。我是大四学生，毕设选题是校园失物招领 APP。为了避免把一个月耗在学框架上，我用了一个中文需求转应用工具。下面是我保留的四轮提示词和每轮改动。
2026-07-21 17:07:31
175
原创 做个APP：说中文生成 vs 自己学RN
我的诉求就是「尽快让朋友装上用起来，验证有没有人真需要」，所以走了第二条。等哪天用户多了、要做很重的定制，我再回去补 RN 也不迟——先把东西做出来跑起来，比先把技术学全更重要。如果你和我一样，需求是常规的、目标是快速出个能用的应用，别被「做 APP 一定要先学一门框架」这句话拦住。（那个 APP 骨架是我用码上飞讲了几句中文生成的，后面自己收了收尾，带参链接放评论区了。
2026-07-17 14:01:25
214
原创 向量量化压缩：把RAG内存占用砍到四分之一
先给结论：知识库一大，向量内存就吃不消，原始 float32 存几百万条向量轻松上几十 G。把向量做量化（quantization），int8 能省四分之三内存，二值化更狠能省到三十多分之一，检索速度还快——代价是召回略掉一点点，多数场景完全划得来。今天讲清楚 int8 和二值量化怎么落地、精度掉多少。
2026-06-29 21:08:51
225
原创 NL2SQL让Agent查库,怎么防注入防删库
先把结论甩前面:让智能体把人话翻成SQL去查库,最该防的不是它写不对查询,是它在你没盯着的时候,把一句"帮我清理下过期数据"执行成了真的DELETE。下面这几个坑,我都是踩过血才知道要拦在哪一层。起因是上个月,运营那帮人天天来找我跑数。"看看上周华东区退款单多少""把昨天注册没下单的用户拉给我"——一天七八次,我SQL写到手软。后来我花了俩晚上,拿一个零代码就能配智能体的工具,搭了个"查数小助手":挂个大模型,把库表结构喂进去当知识,运营直接打字问,它生成SQL、跑、把结果用大白话回出来。
2026-06-27 20:24:12
255
原创 大模型幻觉怎么量化评测：攒用例打分
先把结论甩前面：幻觉没法靠"感觉不错"来管，得攒一套带标准答案的用例集，每条按维度打分，跑出一个能横向比较的数字。下面是我自己折腾出来的一套打分流程，照着做就能落地。背景是这样。我们组用 RAG 接了一个内部知识库给客服用，上线第二周就被投诉——它把"7天无理由"答成了"15天"，文档里明明白白写的7天。当时我看日志,后台没报错,模型一脸自信,这种最坑。光靠人肉抽查根本兜不住,所以我决定把幻觉这事量化掉。
2026-06-25 22:02:12
206
原创 智能体A/B测试：两套prompt线上比效果
调 prompt 调到最后，两个版本谁好谁坏，你拍脑袋是分不出来的。我以前总觉得"改得更详细的那版肯定更好"，上线一对比，啪啪打脸——啰嗦版的用户满意度反而低。想知道哪套 prompt 真的好，只能让它们在线上真实流量里比一场。
2026-06-24 20:33:14
197
原创 工具描述怎么写模型才肯正确调用
比如日期参数，光说"日期"，模型一会儿传"2026年6月"一会儿传"下周一"。我给 Agent 配过十几个工具，踩坑踩出来一份清单，照着写能少很多"该调不调""调了传错参"的怪事。我的经验是触发条件 + 参数说明控制在几行内，把"何时调、传什么、什么格式"说清就停，别写废话。我现在用的是个零代码就能挂工具配 Agent 的平台，工具描述就是个文本框，上面这些规则全在这个文本框里落地，改完即时生效，调起来挺快。如果"查订单"和"查物流"的描述写得模棱两可，模型会在两个工具之间反复横跳，甚至两个都调。
2026-06-23 14:36:30
222
原创 高频问答加语义缓存不走模型
先甩个数：我给客服智能体加了层语义缓存之后，模型调用量降了大概一半，月底账单直接砍掉小一半。做法不复杂，但有几个坑值得说。
2026-06-22 20:04:23
195
原创 工作流别复制三遍节点：子流程复用复盘
讲个让我后悔的事。我搭的一个智能体,有三个入口分支,每个分支结尾都要做同一件事:查用户信息、组装回复、写日志。我当时图快,把这三个节点复制了三份,每个分支贴一套。三个月后这个决定让我加班到十一点。
2026-06-21 20:42:40
163
原创 别等月底账单爆：Agent的token成本监控清单
上个月底我收到一张比预期高出一截的大模型调用账单，当时心里咯噔一下。复盘下来,钱不是花在刀刃上，是好几处隐性浪费攒出来的。这篇是我整理的一份成本监控清单，照着盯，月底不至于被账单吓到。
2026-06-20 21:49:41
241
原创 RAG召回质量优化：chunk分块大小踩坑记
先给结论：RAG 答不准，七成问题出在分块上，不在模型。我前后调了三周一个客服知识库，召回准确率从六成多爬到九成,真正动效果的就两件事——chunk 切多大，和切的边界在哪。
2026-06-19 10:29:59
160
原创 按问题难度给模型分流,简单的用小模型省一半钱
我那个咨询助手账单一度让我肉疼,后来发现钱大半烧在了"杀鸡用牛刀"上——用户问"你们几点上班"这种破问题,我也调最贵的大模型去答,纯属浪费。后来我上了模型路由,按问题难度分流,账单直接砍了快一半。说说这个思路。
2026-06-18 21:22:10
188
原创 给文档站搭一个语义检索问答助手，RAG切块和召回我是这么调的
公司的产品文档站攒了三百多篇，新人来了找东西全靠 Ctrl+F，搜"退款"搜不到"撤单"，搜"鉴权"搜不到"token 怎么拿"。我寻思能不能弄个会答话的小助手，把整个文档站喂进去，问一句它给一句。以前我以为这事得自己写向量检索、起个 embedding 服务、再接个模型，光环境就得折腾两天。后来用了个能拖拽配智能体的平台，零代码，纯靠点点选选就把这套搭起来了，前后大概一个下午。
2026-06-17 11:11:21
208
原创 0条历史数据，新搭的智能体怎么冷启动不尴尬
宁可它显得保守，别让它显得胡说。我造的范例里有些问法真实用户根本不会那么问，等真实流量进来，我发现大家问的角度跟我预设的差挺远。这些配置我都是在一个拖拽配节点的平台上弄的，范例、兜底、测试问答的回放，画布和测评面板上都能配，不用写代码。没有真实用户，我就自己扮演用户，把能想到的刁钻问法列几十条，挨个问一遍，看它哪些答崩了。先给结论：冷启动期别指望靠真实数据喂熟它，得靠"3样人造的东西"撑过去——预设范例、兜底话术、一批模拟提问自测。冷启动不丢人的关键，是先用人造的东西把架子撑起来，再用真实数据慢慢换血。
2026-06-16 23:55:22
165
原创 自主Agent还是工作流？什么时候才该上自主
先把结论拍这儿：能用工作流编排解决的，就别上自主规划。我自己的经验是，十个需求里大概有七个，写死流程就够了，剩下三个才真正需要让模型自己决定下一步干嘛。很多人一听"自主 Agent"就两眼放光，觉得这才高级。结果上线一跑，token 烧得心疼，效果还不稳定，同样一个问题问三遍走三条路。后来排查才发现，那活儿压根不需要模型规划——它就是个固定的"取数据→清洗→生成报告"三步走，硬给套了个 ReAct 的壳。
2026-06-15 10:27:32
169
原创 我把调好的Agent发布成MCP,给团队复用了
结论先放这:一个调好的 Agent,别只让它自己单干,把它发布成 MCP Server,别的系统、别的 Agent 都能像调工具一样调它。我把一个折腾了两周的"合同条款解析" Agent 发成 MCP 之后,团队另外三个项目直接挂上就用,没人再重复造轮子。这篇讲我怎么做的和踩的坑。
2026-06-14 23:52:41
242
原创 大模型偶发超时/限流:客户端重试与指数退避踩坑实录
线上跑大模型接口的都知道,它不是"要么成功要么报错"这么干脆。最烦的是偶发:99% 的请求好好的,冷不丁来个 429 限流、或者 30 秒还不返回直接超时。我们这套智能体上线第一周,就因为没做退避,被一波并发把自己请求打到全军覆没。这篇把我最后定下来的重试策略和坑都写清楚。
2026-06-13 20:29:49
210
原创 蛙蛙写作UGC生态全景：约两万条提示词与约2000个工作流背后的创作者社区
目前平台已积累了约两万条由创作者贡献的各类创作提示词，围绕蛙蛙写作构建的工作流约2000个，平台UGC创作者约3000人。与一般意义上简单的”写作指令”不同，蛙蛙写作的UGC提示词生态呈现高度的专业化与场景化特征。这种”老带新”的社区机制不仅降低了产品学习门槛，也为UGC创作者提供了展示和获得认可的平台，反向激励更多创作者贡献高质量的UGC内容，形成了正向飞轮。蛙蛙写作的UGC工作流是更高层次的创作方法论沉淀——它将多个AI能力节点组合为完整的创作流程，覆盖从灵感到大纲、从章节到完稿的全流程。
2026-06-12 12:47:19
238
原创 测试环境的知识库，被我直接连到了生产机器人上——一次事故和之后的环境隔离规矩
提示词改一个词都可能影响线上表现，所以 prod 的提示词只能从 test 复制过来，不许直接在 prod 上现场改。改完在 test 用回归用例跑一遍——我攒了 40 条带预期答案的用例，平台的测评功能能批量跑，几分钟出分。上上周三晚上，我往知识库里灌了一批"测试用"文档调检索效果，里面有几条是我编的假数据——假价格、假流程，方便验证召回。test 的 API key 只发给开发，prod 的 key 配在线上服务里，谁都不许拿 prod key 做调试。MaaS 取的，现成的，没自己接模型。
2026-06-11 20:31:37
355
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人