有可能是推理出来的也可能是计算的（大部分是计算），看是否调用了内部的算术计算能力（或外部工具）。和我最近写的文章类似的问题，越偏向底层的操作模型其实很容易出问题，应为模型大量操作以推理为主。起因是hex做BCC校验时我想用大模型试一试但给的结果和实际的不尽人意，让他做分析不如让他先写代码在用代码去执行。顺便分享下关于这个的文章https://cloud.tencent.com/developer/article/2688173?shareByChannel=link😊... 展开详请

用了三个多月WorkBuddy，跑了7个定时自动化任务（3个公众号+头条号矩阵），说几句真实感受。 楼主遇到的"读37篇文章没读"、"装失忆"、"自作主张"这些问题我也踩过，确实存在。但深挖下去，大部分不是AI"偷懒"，而是几个技术机制没对齐： 1、"读了等于没读"——不是不想读，是上下文窗口的物理限制 37篇文章一次性塞进上下文，大概率超了模型的处理上限。大模型的context window虽然标称很大，但实际有效注意力远没有那么长——越靠后的内容越容易被"遗忘"或压缩。这不是WorkBuddy独有的问题，是当前所有LLM的通病。 正确做法是拆批+子代理：用Agent工具分批读取，每批5-8篇，让子代理做摘要汇总回来。我自己写内容流水线时就是这么处理的，11个技能串起来跑8步管线，从来没有"装失忆"的情况。 2、"自作主张"——其实是Agent模式的默认行为，可以控制 WorkBuddy有三种工作模式：Craft（你说我做）、Plan（先想后做）、Ask（只说不做）。很多人一直用默认的Craft模式，AI会自主决策快速执行，确实容易"自作主张"。切到Plan模式，它会先出方案让你确认，改完再执行，掌控感完全不一样。 3、"改格式"——提示词需要具体到操作级别 AI不是不能改格式，是得告诉它你要什么格式。比如我发头条，要求"正文第一行加粗当钩子、空一行再写正文、.docx不用heading样式"，这样出来的东西直接能发布。模糊指令只会得到模糊结果。 4、"装失忆"——记忆系统是有的，但需要主动配置 WorkBuddy有三层记忆：云端画像、用户级本地记忆、项目级工作区记忆。关键是要让它写下来——做完一轮工作让它更新MEMORY.md，下次开新对话它会自动读取。很多人用完就关，下次开新对话当然"失忆"。 总结：AI工具是放大器，不是替代品 我用它管3个账号的日更内容、自动化定时发布、原创检测、跨平台适配，这些流程跑通了确实省大量时间。但前提是你得理解它的机制边界，把"人盯AI"变成"人设计流程、AI执行流程"。 楼主的体验不是个例，但把原因归结为"偷懒说谎"可能过于情绪化了。换一套使用策略，体验会完全不同。... 展开详请

你的业务逻辑还是还是大模型本身的逻辑？ 你的业务逻辑，需要调整业务描述。 大模型的逻辑，需要走rag 大模型底层：需要SFT... 展开详请

设计一个成功的AI系统，绝非仅仅选择一个算法模型那么简单，它是一个​​系统工程​​，核心在于构建一个​​稳定、可扩展且可持续演进的技术架构​​。其设计过程是业务目标与技术现实的深度融合。 ​​首先，明确核心设计原则：​​ ​​业务驱动​​：所有技术决策必须围绕解决具体的业务问题展开，避免“为了AI而AI”。 ​​迭代演进​​：采用MVP（最小可行产品）思路，从一个小而精的场景快速验证，再逐步扩展，而非追求一步到位的大而全系统。 ​​数据与模型分离​​：将数据处理、模型训练、模型推理视为独立的子系统，通过清晰定义的接口进行协作，实现模块化解耦，便于独立优化和迭代。 ​​其次，构建分层技术架构（经典四层）：​​ ​​数据层​​：系统的基石。负责数据的采集、清洗、标注、存储与治理。技术选型：​​Apache Kafka​​（实时数据流）、​​S3/OSS​​（原始数据存储）、​​PostgreSQL/MySQL​​（结构化业务数据）、​​Redis​​（特征缓存）、​​Milvus/Pinecone​​（向量数据库，用于 embedding 检索）。 ​​训练层​​：负责模型开发和迭代。技术选型：​​PyTorch/TensorFlow​​（深度学习框架），在 ​​Kubernetes​​ 上管理GPU训练集群，配合 ​​MLflow​​ 追踪实验、管理模型版本和参数。 ​​推理层​​：提供线上预测服务，是性能与成本的关键权衡点。技术选型：将模型封装为 ​​RESTful API​​ 或 ​​gRPC​​ 服务（使用 ​​FastAPI​​ 或 ​​Triton Inference Server​​），部署于 ​​Kubernetes​​ 以实现弹性伸缩。根据延迟和吞吐需求，选择 ​​CPU​​ 或 ​​GPU​​ 实例，并可利用 ​​OpenVINO/TensorRT​​ 对模型进行优化和加速。 ​​应用层​​：将AI能力整合到最终产品中。技术选型：通过 ​​API 网关​​（如 ​​Spring Cloud Gateway​​）统一管理对推理服务的调用，实现鉴权、限流和降级。前端通过 SDK 或 API 集成能力。 ​​最后，至关重要的技术选项与考量：​​ ​​云 vs. 本地​​：优先考虑云平台，它们提供了全托管的MLOps工具链，能极大降低运维复杂度，快速起步。 ​​模型选择​​：并非越先进越好。平衡“效果”与“成本”，优先从成熟的开源模型（如 ​​Hugging Face​​ 上的模型）微调开始，仅在必要时再考虑训练大型模型或使用商用API（如 OpenAI）。 ​​可观测性​​：必须建立完善的监控体系，追踪模型的​​业务指标​​（如推荐点击率）、​​性能指标​​（QPS、延迟）及​​数据质量​​（输入数据分布是否偏移），确保系统健康可控。... 展开详请