今日数据概览
峰值活跃时段
21:00
该时段共 46 条消息
Top 发送者
wxid_a4ptxb0fnv7b21
发送 80 条
热门主题
模型
共 16 次提及
热门链接数量
5
例如：www.anthropic.com
群氛指数
64
讨论平稳
要点速览
- 消息 292 条，活跃 27 人；峰值 21:00-21:59
- Top 发送者：wxid_a4ptxb0fnv7b21(80)、wxid_xsrpijjy5ljx22(39)、wxid_oseqiupd2olm22(33)
- 热门主题：模型、现在、操作
- 热门链接 5 个，例如 www.anthropic.com
- 图片 26 张
群氛温度计
活跃度
100%
综合消息量与参与度
情绪指数
51%
正向表达占比
信息密度
30%
链接/长文/资料占比
争议度
18%
问答、@ 提及、感叹
氛围解读
- 活跃度高（292 条、27 人参与）
- 讨论较温和，可适度引导观点碰撞
AI 洞察
2025年12月8日群内围绕RAG增强决策、PRD方法论、AI工程化等议题展开深度讨论，技术氛围浓厚，协作意愿强。
值得关注
- RAG讨论聚焦“逻辑节点约束生成”，超越传统文本检索
- PRD价值再审视：补写PRD成产品迭代新策略
- Technology类任务被确认为高频且高成本的核心场景
- 多位成员探索AI驱动的开发状态分析与自动化工具
潜在机会
- 推动“决策型RAG”原型验证，整合图谱与流程编排
- 沉淀PRD与快速Demo的适用边界指南
- 共享国内垂类RAG实践案例，避免重复踩坑
风险与预警
- 关键问题如“垂类RAG效果”“训练必要性”未获明确答复
- 部分成员对AI工具链（如Gemini、Notion AI）稳定性存疑
- 需求分析与Agent框架缺乏行业共识，易造成碎片化
建议行动
- 组织小型分享会，由wxid_a4ptxb0fnv7b21演示GraphRAG+流程编排方案
- 汇总未回复问题清单，定向邀请相关专家跟进
- 建立“AI工程化模式库”，收录PRD、Agent、RAG等实践模板
今日金句：“先开枪后画靶子”——快速原型后反向提炼PRD，成为敏捷AI产品新范式
互动热度
00
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
回复债
待跟进问题
28
尚未收到回应
平均响应
20.7
分钟/问题
最佳催办时段
21:00
21:0022:0000:00
待回复
-
wxid_a4ptxb0fnv7b21 · 你意思是用rag搜索去做逻辑性判断？
已等待 1330 分钟
-
wxid_a4ptxb0fnv7b21 · 搜索结果去处理流程节点？
已等待 1329 分钟
-
wxid_sslklnkpm49h22 · 那我们说的是一回事？
已等待 1324 分钟
-
wxid_sslklnkpm49h22 · 这个目前搞下来的效果怎么样？
已等待 1265 分钟
-
wxid_sslklnkpm49h22 · 如果不搞训练，能不能解决？
已等待 1265 分钟
-
wxid_5ym74lhv5sa311 · 可以试试用LLM猜用药的方案然后用那个方案算embedding相似度。性能怎么样未知
已等待 1206 分钟
-
wxid_xsrpijjy5ljx22 · 直接让claude code读你所有的记录不可以吗？
已等待 1172 分钟
-
wxid_sslklnkpm49h22 · 你的思路要和要解决的痛点是什么？
已等待 1163 分钟
-
wxid_xsrpijjy5ljx22 · 这里的挑战不是工具，而是方法论。 你怎么分析？需要看什么材料？怎么identify risk？
已等待 1112 分钟
-
wxid_ti12isxsaza622 · CC怎么知道你想要什么呀，他看代码也不知道呀
已等待 1040 分钟
-
wxid_sslklnkpm49h22 · 不行啊，达不到业务要求，现在国内垂类的RAG哪家做得最好？
已等待 881 分钟
-
wxid_oseqiupd2olm22 · 大家理解的 PRD 不知道是否是一个东西
已等待 836 分钟
-
oldbruce · 🔧 Technology 类别：为什么既昂贵又高频？
根据报告中对类别结构、模型使用模式以及不同提供商的标签分布，可以推断 Technology 类别具备以下特征：
1. 高频（High Frequency）——技术类任务在大量真实工作…
已等待 782 分钟
-
netcmcc · 有企业订阅的是不是好一点？我准备今天试试。
已等待 737 分钟
-
xukeqian · 学生账号？
已等待 733 分钟
-
xukeqian · 我就是这样的，如果账号被定性，而不是上网位置，就比较麻烦
已等待 722 分钟
-
wxid_9vce704q93o421 · go项目，很多会用gin，gin本身的优劣和其他框架的对比不说，就是有一个小共识用gin，现在哪个agent开发框架有这个小共识？
已等待 675 分钟
-
netcmcc · 这个共识有什么阻碍吗？你写提示时的时候手动指令一下？
已等待 667 分钟
-
oldbruce · 这是张楠那个文章里的？
已等待 610 分钟
-
wxid_xsrpijjy5ljx22 · 谭老板认识作者不？
已等待 517 分钟
-
wxid_a4ptxb0fnv7b21 · 需求分析， 定多步操作 ，然后执行一步之后 通过 playwright 判断页面是否变化，变化就 重新 vl 读图 + 之前未完成步骤 ，更新步骤后 继续操作
已等待 491 分钟
-
wxid_jchnxbewx45k21 · 为啥一定要用mcp或者vl的方式呢？
已等待 464 分钟
-
AIi_AIi · 感觉你这个可能都能封装成个啥东西出来了？
已等待 336 分钟
-
wxid_oseqiupd2olm22 · 你前期都用什么mcp？
已等待 153 分钟
-
netcmcc · 单md？
已等待 89 分钟
-
wxid_ti12isxsaza622 · 那个 面板 是一个 什么？ 一个 MD 么 ？
已等待 84 分钟
-
inntran · 感觉就像小孩，别说“不要如何如何”，越说越会去做
已等待 78 分钟
-
wxid_ti12isxsaza622 · 这种事 负面 教材 对不 ？
已等待 63 分钟
已解决
-
wxid_sslklnkpm49h22 · 上周马工的分享后来有小结吗？前几天的临时meeting 有AI笔记吗？
回复：wxid_xsrpijjy5ljx22用时 152.5 分钟
-
wxid_sslklnkpm49h22 · RAG 方面，有没有搞过一些专业的书籍、操作指南手册的例子 @Player¹ ，结果是可操作可决策的，不是泛知识的内容，这方面的进展和坑如何？
回复：wxid_a4ptxb0fnv7b21用时 4.9 分钟
-
wxid_oseqiupd2olm22 · 另外，马工截图中显示的是“补 PRD”（把已有系统的 PRD 提取出来），借此来解决“下一个新 feature 怎么规划”的难题
回复：wxid_a4ptxb0fnv7b21用时 8.9 分钟
-
netcmcc · 时隔几个月，我发现Google的Gemini CLI和cc比差别还是很大，任务完成性不是很高，有时候都不会去读写文件，大家是这种感觉吗？那他的优势在哪里？
回复：whb-9519用时 0.9 分钟
-
terryso · 每一步都是通过截图让大模型去理解来操作？
回复：wxid_a4ptxb0fnv7b21用时 1.5 分钟
-
wxid_jchnxbewx45k21 · 这个不能直接写playwrite的代码，去控制操作路径和进行断言吗？
回复：wxid_a4ptxb0fnv7b21用时 2.5 分钟
-
wxid_a4ptxb0fnv7b21 · 哈哈哈哈 舒服了 纯粹 vl 视觉模型方案 能搞定了 最麻烦的 已经搞成了， 纯粹的视觉定位，没有 selector 没用 css 定位，没用 mcp 读 html 的 dom 树。 完全可用的穿透 shadowroot
回复：AIi_AIi用时 4.2 分钟
-
waynewang · 那你们需求管理怎么做？
回复：wxid_xsrpijjy5ljx22用时 31.2 分钟
-
wxid_ti12isxsaza622 · 这个会么？ 我感觉 所有的历史对话 这个 上下文 其实 不算多
回复：wxid_xsrpijjy5ljx22用时 3.3 分钟
-
AIi_AIi · 兄弟们。。我去冲了ProductHunt。。欢迎帮忙转发顶顶，看看有没有新流量https://www.producthunt.com/products/huan-ai-talent-flow
回复：wxid_oseqiupd2olm22用时 16.3 分钟
-
wxid_oseqiupd2olm22 · 挺猛的。一个人吗？也费人脑token吧
回复：xukeqian用时 1.6 分钟
群内热议
Top 发送者
-
wxid_a4ptxb0fnv7b21 · 80 条
-
wxid_xsrpijjy5ljx22 · 39 条
-
wxid_oseqiupd2olm22 · 33 条
-
wxid_ti12isxsaza622 · 26 条
-
wxid_sslklnkpm49h22 · 16 条
热门链接
-
www.anthropic.com
来源：www.anthropic.com
-
OpenRouter 100 万亿 Token 实证研究
来源：mp.weixin.qq.comOpenRouter 100 万亿 Token 实证研究摘要本实证研究分析了 OpenRouter 平台上超过
-
docs.siliconflow.cn
来源：docs.siliconflow.cn@杨攀🏂🎾#硅基流动 老哥
-
midscenejs.com
来源：midscenejs.com@anhui 大佬 打扰一下，之前你提到的 UI 自动化试试这个： ，这个我看了他的实现， 是通过 读取整个 dom 去做操作的 ，你们后面接的 A…
-
Anthropic CEO达里奥·阿莫迪：2014年我在百度工作时，从没想过自己有一天能执掌头部AI公司。#AI #AGI #人工智能 #Anthropic #达里奥·阿莫迪 #claude #百度 #钛媒体 #钛媒体AGI
来源：wxapp.tc.qq.com
主题概览
-
模型 · 16 次
代表内容：🔧 Technology 类别：为什么既昂贵又高频？ 根据报告中对类别结构、模型使用模式以及不同提供商的标签分布，可以推断 Technology 类别具备以下特征： 1. 高频（High Frequency）——技术类任务在大量真实工作流中出现 在“Categories”和“Author-level insights”部分有这些关键观察： ● 大模型使用正在从简单问答转向复杂、结构化工作流 技术类任务（如系统设计、架构评审、基础设施推演、硬件/软件选型）属于需要长期上下文、较长 prompt、较长推理链的典型工作负载。这与： prompt token 多年持续增长（已 4x） completion token 增长（几乎 3x） reasoning 模型使用量超过 50% 长序列主要由 Programming & Technology 驱动 完全一致。 技术类任务并不像娱乐、角色扮演那样是“可选的”，它们往往是生产级决策流程的一部分，因此出现在大量开发者的日常工作里，属于稳定且持续高频的类别。 2. 昂贵（Expensive）——技术类任务天然具有高 token 消耗与高模型要求 技术类别之所以昂贵，原因来自报告中多项趋势： ● 需要大模型 + 推理模型 在作者分布中： Anthropic Claude（主要用于 Programming + Technology，占比 >80%） OpenAI（向 Programming + Technology 迁移，合计 >55%） Google（Technology 是其最稳定的高比重类别之一） 这些模型都是“贵模型”，即单位 token 成本高于一般聊天模型。 ● 技术任务需要长输入（复杂背景 + 文档 + 架构图描述） “Prompt Tokens on the Rise” 与 “Programming as the Main Driver Behind Prompt Token Growth” 说明： Technology 与 Programming 一样，是长上下文任务 平均输入可达数千到上万 token 推理型模型生成大量中间 reasoning tokens → 直接导致费用数倍以上 ● 技术任务对 质量/可靠性 的要求高 → 用户更愿意付溢价 技术类任务通常涉及： 架构可靠性 成本评估 API 设计 安全性分析 数据流/系统工程 生产级流程（workflow orchestration） 这些任务的错误代价远高于写故事或翻译，因此用户倾向选择昂贵的顶级模型。 3. 在所有高价值类别中，Technology 是唯一同时具备“高频 + 高成本”的 对比页面中的各大类别： 类别 高频？ 单价/成本？ 为什么不构成“高频 + 昂贵”组合？ Roleplay 高频 低成本（常用 OSS） 大量使用开源模型，低价高量；不是“昂贵类别” Programming 高频 中高成本 虽然 token 多，但很多使用 OSS coder 模型 → 成本平均化 Translation 高频但便宜 较低 常转向轻量模型 Science 较低频 高成本 但总体量远不足以构成“高频类别” General Q&A 高频 低成本 多用小模型；任务简单 Technology ✔ 高频 ✔ 高成本 模型质量需求极高，长上下文 & reasoning-heavy 因此，在所有主要类别中，只有 Technology 同时满足： ✔ 高频 ✔ 高 token 消耗 ✔ 用户愿意支付溢价 ✔ 倾向使用昂贵的 frontier models / reasoning models ✔ 常出现在专业生产环境 🧭 Technology 类别具体包含哪些任务？ 从页面的分类体系与作者分布推断，Technology 通常包括： 系统架构设计（system design） 分布式系统分析 数据工程 / pipeline 规划 API 规范设计 安全与威胁建模 性能/扩展性分析 硬件架构（如 GPU、TPU、加速器）选择与能力分析 云架构（AWS/GCP/Azure）对比 DevOps / infra / SRE 相关推理 复杂 technical documentation 分析 这些任务具备共同点： 输入长 → 阅读整个系统描述、文档、代码库 推理链长 → 需要规划、比较架构、做 trade-off 错误代价大 → 用户不会用便宜模型 付费意愿高 → 属于企业级决策支持 所以 Technology 显然具备“唯一真正同时昂贵且高频的类别”的特征。
-
现在 · 16 次
代表内容：🔧 Technology 类别：为什么既昂贵又高频？ 根据报告中对类别结构、模型使用模式以及不同提供商的标签分布，可以推断 Technology 类别具备以下特征： 1. 高频（High Frequency）——技术类任务在大量真实工作流中出现 在“Categories”和“Author-level insights”部分有这些关键观察： ● 大模型使用正在从简单问答转向复杂、结构化工作流 技术类任务（如系统设计、架构评审、基础设施推演、硬件/软件选型）属于需要长期上下文、较长 prompt、较长推理链的典型工作负载。这与： prompt token 多年持续增长（已 4x） completion token 增长（几乎 3x） reasoning 模型使用量超过 50% 长序列主要由 Programming & Technology 驱动 完全一致。 技术类任务并不像娱乐、角色扮演那样是“可选的”，它们往往是生产级决策流程的一部分，因此出现在大量开发者的日常工作里，属于稳定且持续高频的类别。 2. 昂贵（Expensive）——技术类任务天然具有高 token 消耗与高模型要求 技术类别之所以昂贵，原因来自报告中多项趋势： ● 需要大模型 + 推理模型 在作者分布中： Anthropic Claude（主要用于 Programming + Technology，占比 >80%） OpenAI（向 Programming + Technology 迁移，合计 >55%） Google（Technology 是其最稳定的高比重类别之一） 这些模型都是“贵模型”，即单位 token 成本高于一般聊天模型。 ● 技术任务需要长输入（复杂背景 + 文档 + 架构图描述） “Prompt Tokens on the Rise” 与 “Programming as the Main Driver Behind Prompt Token Growth” 说明： Technology 与 Programming 一样，是长上下文任务 平均输入可达数千到上万 token 推理型模型生成大量中间 reasoning tokens → 直接导致费用数倍以上 ● 技术任务对 质量/可靠性 的要求高 → 用户更愿意付溢价 技术类任务通常涉及： 架构可靠性 成本评估 API 设计 安全性分析 数据流/系统工程 生产级流程（workflow orchestration） 这些任务的错误代价远高于写故事或翻译，因此用户倾向选择昂贵的顶级模型。 3. 在所有高价值类别中，Technology 是唯一同时具备“高频 + 高成本”的 对比页面中的各大类别： 类别 高频？ 单价/成本？ 为什么不构成“高频 + 昂贵”组合？ Roleplay 高频 低成本（常用 OSS） 大量使用开源模型，低价高量；不是“昂贵类别” Programming 高频 中高成本 虽然 token 多，但很多使用 OSS coder 模型 → 成本平均化 Translation 高频但便宜 较低 常转向轻量模型 Science 较低频 高成本 但总体量远不足以构成“高频类别” General Q&A 高频 低成本 多用小模型；任务简单 Technology ✔ 高频 ✔ 高成本 模型质量需求极高，长上下文 & reasoning-heavy 因此，在所有主要类别中，只有 Technology 同时满足： ✔ 高频 ✔ 高 token 消耗 ✔ 用户愿意支付溢价 ✔ 倾向使用昂贵的 frontier models / reasoning models ✔ 常出现在专业生产环境 🧭 Technology 类别具体包含哪些任务？ 从页面的分类体系与作者分布推断，Technology 通常包括： 系统架构设计（system design） 分布式系统分析 数据工程 / pipeline 规划 API 规范设计 安全与威胁建模 性能/扩展性分析 硬件架构（如 GPU、TPU、加速器）选择与能力分析 云架构（AWS/GCP/Azure）对比 DevOps / infra / SRE 相关推理 复杂 technical documentation 分析 这些任务具备共同点： 输入长 → 阅读整个系统描述、文档、代码库 推理链长 → 需要规划、比较架构、做 trade-off 错误代价大 → 用户不会用便宜模型 付费意愿高 → 属于企业级决策支持 所以 Technology 显然具备“唯一真正同时昂贵且高频的类别”的特征。
-
操作 · 13 次
代表内容：@anhui 大佬 打扰一下，之前你提到的 UI 自动化试试这个：https://midscenejs.com/index.html，已经在真实项目上用了一阵子了，目前没碰到啥硬伤 ，这个我看了他的实现， 是通过 读取整个 dom 去做操作的 ，你们后面接的 AI 模型是用的 API 还是 自己搭建的服务器
-
直接 · 15 次
代表内容：🔧 Technology 类别：为什么既昂贵又高频？ 根据报告中对类别结构、模型使用模式以及不同提供商的标签分布，可以推断 Technology 类别具备以下特征： 1. 高频（High Frequency）——技术类任务在大量真实工作流中出现 在“Categories”和“Author-level insights”部分有这些关键观察： ● 大模型使用正在从简单问答转向复杂、结构化工作流 技术类任务（如系统设计、架构评审、基础设施推演、硬件/软件选型）属于需要长期上下文、较长 prompt、较长推理链的典型工作负载。这与： prompt token 多年持续增长（已 4x） completion token 增长（几乎 3x） reasoning 模型使用量超过 50% 长序列主要由 Programming & Technology 驱动 完全一致。 技术类任务并不像娱乐、角色扮演那样是“可选的”，它们往往是生产级决策流程的一部分，因此出现在大量开发者的日常工作里，属于稳定且持续高频的类别。 2. 昂贵（Expensive）——技术类任务天然具有高 token 消耗与高模型要求 技术类别之所以昂贵，原因来自报告中多项趋势： ● 需要大模型 + 推理模型 在作者分布中： Anthropic Claude（主要用于 Programming + Technology，占比 >80%） OpenAI（向 Programming + Technology 迁移，合计 >55%） Google（Technology 是其最稳定的高比重类别之一） 这些模型都是“贵模型”，即单位 token 成本高于一般聊天模型。 ● 技术任务需要长输入（复杂背景 + 文档 + 架构图描述） “Prompt Tokens on the Rise” 与 “Programming as the Main Driver Behind Prompt Token Growth” 说明： Technology 与 Programming 一样，是长上下文任务 平均输入可达数千到上万 token 推理型模型生成大量中间 reasoning tokens → 直接导致费用数倍以上 ● 技术任务对 质量/可靠性 的要求高 → 用户更愿意付溢价 技术类任务通常涉及： 架构可靠性 成本评估 API 设计 安全性分析 数据流/系统工程 生产级流程（workflow orchestration） 这些任务的错误代价远高于写故事或翻译，因此用户倾向选择昂贵的顶级模型。 3. 在所有高价值类别中，Technology 是唯一同时具备“高频 + 高成本”的 对比页面中的各大类别： 类别 高频？ 单价/成本？ 为什么不构成“高频 + 昂贵”组合？ Roleplay 高频 低成本（常用 OSS） 大量使用开源模型，低价高量；不是“昂贵类别” Programming 高频 中高成本 虽然 token 多，但很多使用 OSS coder 模型 → 成本平均化 Translation 高频但便宜 较低 常转向轻量模型 Science 较低频 高成本 但总体量远不足以构成“高频类别” General Q&A 高频 低成本 多用小模型；任务简单 Technology ✔ 高频 ✔ 高成本 模型质量需求极高，长上下文 & reasoning-heavy 因此，在所有主要类别中，只有 Technology 同时满足： ✔ 高频 ✔ 高 token 消耗 ✔ 用户愿意支付溢价 ✔ 倾向使用昂贵的 frontier models / reasoning models ✔ 常出现在专业生产环境 🧭 Technology 类别具体包含哪些任务？ 从页面的分类体系与作者分布推断，Technology 通常包括： 系统架构设计（system design） 分布式系统分析 数据工程 / pipeline 规划 API 规范设计 安全与威胁建模 性能/扩展性分析 硬件架构（如 GPU、TPU、加速器）选择与能力分析 云架构（AWS/GCP/Azure）对比 DevOps / infra / SRE 相关推理 复杂 technical documentation 分析 这些任务具备共同点： 输入长 → 阅读整个系统描述、文档、代码库 推理链长 → 需要规划、比较架构、做 trade-off 错误代价大 → 用户不会用便宜模型 付费意愿高 → 属于企业级决策支持 所以 Technology 显然具备“唯一真正同时昂贵且高频的类别”的特征。
-
感觉 · 13 次
代表内容：我的感觉马工的 补 PRD 是因为， PRD 的时间都已经够 做完第一阶段需求了， 所以 从第一次阶段出来的成本 补回PRD 给需求放， 也就是 先开枪 后画了一个靶子上去
关键词热度
模型 · 33现在 · 17prd · 16操作 · 16直接 · 15感觉 · 14成本 · 14类别 · 14高频 · 14technology · 13token · 13任务 · 13上下 · 12上下文 · 12下文 · 12工程 · 12我的 · 12然后 · 12需求 · 12项目 · 12
消息时间线
展开查看 292 条历史消息（仅展示最近 150 条）
很快的 定个语言框架 跟着 review 代码 ， 让 AI 加好注释就行
okok 我用 mcp 去尝试做
我现在用 vl 视觉模型做的 ，感觉除了浪费 tokens 还是挺准的
感谢
我会learn in public
我 react 就是 用这种方案学会的 [破涕为笑]
我立个flag，接下来一个月学习 FreeCAD [加油]
我们用的 Qwen 的视觉模型，你如果重复跑 case 的话开启缓存，只要页面和 case 不变他会读取缓存不会再走模型，执行会快很多，而且也不消耗 token
每一步都是通过截图让大模型去理解来操作？
需求分析， 定多步操作 ，然后执行一步之后 通过 playwright 判断页面是否变化，变化就 重新 vl 读图 + 之前未完成步骤 ，更新步骤后 继续操作
okok， 明白了
@Nick@保利威视频
我的方案
也有恶心的 baidu 首页 路由不跳转 但是页面 整个元素变了
拉倒了 不考虑这种特殊情况
我之前测试碰到我们管理后台，很多搞不定。尤其那些需要hover上去显示菜单，有另外操作的
从源头把这些奇技淫巧禁掉
其实可以把PRD的内涵定义更清楚一点，我自己觉得PRD过于死板，Demo深度如果到100%可确认就过于复杂，要找个结合部。
[裂开] 卧槽 hover 菜单 我忘记了，不过还好， 可以用 mouse over 处理
playwright mcp能搞定[偷笑]
成功了 [让我看看] 卧槽
缺点是 靠 vl 真慢
这个不能直接写playwrite的代码，去控制操作路径和进行断言吗？
为啥一定要用mcp或者vl的方式呢？
两个需求， 我之前的 录制 回放能力 就是用的 playwrite的代码 去实现的
我现在是通过自然语言描述 让 AI 自己去意图识别，然后进行自动化操作 实习需求
最关键是 我公司的这边的前端 不是 前后端分离的， 是服务端渲染技术，页面里面有 shadowroot 没有办法直接用 playwright 穿透
我的想法是 ，后面模型能力越来越强，速度越来越快 那么 VL 的方案就会越来越厉害
了解了
VL一定是最贵的方案得用在合适的地方
[旺柴] 感谢 硅基流动， 我测试一下午了 花了一毛钱
就是稍微有点慢
你可以写一篇权威UI测试实战总结了[强]
要求太高。码农只会微信群写点零散的消息，一般写不出500字以上的文章
文章的核心是逻辑，这是程序员的天生优势，AI再补充外在的辞藻，完全够了
文章的核心是读者。
大多数码农写的文章没有targeted audience，很喜欢塞无关紧要的代码片段
@linhow 卧槽 我搞出来了
哈哈哈哈 舒服了 纯粹 vl 视觉模型方案 能搞定了 最麻烦的 已经搞成了， 纯粹的视觉定位，没有 selector 没用 css 定位，没用 mcp 读 html 的 dom 树。 完全可用的穿透 shadowroot
[强]
最近微软给了个开源的UI执行模型，fare7B，成本和token消耗低非常多
fare7B 对对对，我之前和 grok聊的给我推荐的也是这个
也就是纯 vl 模型
感觉你这个可能都能封装成个啥东西出来了？
我们自己开发的那些东西是不是也能基于这个方案做测试
可以啊 我都已经用 electron 封装成 app 了
我这用起来如果模型 速度起得来，比 https://midscenejs.com/index.html 这个都方便，我甚至是一个浏览器了 ，都不用注入代码，直接用纯粹的 vl 去处理逻辑，真正 0 代码 [奸笑]
干，我的激将法对@Player¹ 无效
哈哈哈哈
[强]牛逼。我找个周末学习一下你这个UI测试
[坏笑]
share个方案，具体大家自行搜一下，目前team使用还算稳定
就是得找个国外的朋友帮你放这个机器
我们长期就是在加州放一台Mac
[强]这个好
真正的码农对美女激将都没感觉，出去度假要配置happy code，陪老婆逛商场要带两个屏幕，为了AI编程自由出国工作
@Lex 借助AI一个月学习前端现在可以理解，你这一个月从程序员跨到机械CAD，是不是有些小瞧机械工程啊
机械工程可不是软件工程谁都能试试看
周末看了几个入门视频，希望能挑战一下
Anthropic CEO达里奥·阿莫迪：2014年我在百度工作时，从没想过自己有一天能执掌头部AI公司。#AI #AGI #人工智能 #Anthropic #达里奥·阿莫迪 #claude #百度 #钛媒体 #钛媒体AGI
他到底当年在百度遭遇了啥
…
这个学习，估计AI也帮不上忙吧
很难，很多时候你能模糊知道想要找个什么功能，但是面对那几十个按钮和弹出窗口是完全懵逼的
我换着花样问AI，但是每次给我的操作流程我都找不着对应的菜单或按钮，幻觉十分严重
最差就是回退到笨办法，啃手册和视频教程
好吧，你这是为万一软件工程大裁员准备一条新路线
更偏个人爱好
软的硬的都玩玩
厉害的[强]
谁都可以转码到软件工程。没见过码农转到传统工程。
说明应该更简单才对
机械工程工资天花板: 一万人民币。。。
机械工程/AI跨界人才目前薪水非常高。
这两年刚刚起来
以前规模不大
增材制造专业挺火的
今天一早我就找了个同事当我的product owner，然后拉着她和cto定了项目的scope和roadmap
后面我和她还有印度小哥就放手开干，不应该有什么会议了
我把mcp都卸载了，尽量保持我的context简单和可知
我的ai只属于我，它的思维不会被外人所污染
你前期都用什么mcp？
mcp消耗上下文tokens外，第三方黑盒属性也确实是个大问题
工程里面这些缺点很突出，理论上的优点效果也不如预期
linear，装了，但是一直没用
太几把难用了
我现在唯一用的 MCP 就是 exa
当前
supabase和chrome dev，我只用这俩
那你们需求管理怎么做？
就三个人，直接md和github就能很好对付了。公司有要求就定期同步一下。
这种典型三人组，需求管理做到有基线，变更，追溯几个基本能力是不是就行了。
我老板让我创建tickets，我创建个毛
我和他定下scope和里程碑，他就不要管我们的过程了
ticket的唯一用处就是外包和他结算，我到时候批量制造一批
是的。
在AI coding的context下，创建和sync ticket的时间，代码都写完了
我理解产品需求，还是要分解成issue的
我直接把md check in到github，有版本
那就是@Nick@保利威视频 的story.md
我现在 搞了一个 单MD 机制来 帮我管理 和客户的沟通， 这个单文本包含了 项目的所有context， 然后所有 历史 conversation， 我觉得还挺方便的。 每次 贴 一个slack 截图， CC 就帮我draft 回复了。
然后我 定义了一个 inline 的comment 机制。。。。 挺实用的
单md？
索引吗
相当于 后面 我和 这个项目 所有客户 沟通的 上下文 ，以及 历史沟通记录都用这个 doc 管理。 这样 以后 别的 cc session 可以非常清晰得 获得上下文
以前我的痛点就是 文档太多了， 新的 cc session 很难知道 整个上下文
我在尝试这个路子了也。之前更新每天项目进度是个很大问题，现在准备给每个同事提要求，每天push到线上的时候，同步让cc更新下工作进度，推到线上，然后项目经理查看一个汇总管理项目的面板
为什么需要所有的上下文。
把所有的历史对话都expose给后续的ai agent，可能引入更多的混乱
因为 沟通的内容 挺烦的， 我们项目 涉及到 几百个 table 里面的细节
这个会么？ 我感觉 所有的历史对话 这个 上下文 其实 不算多
对 AI 来说
不过我还加了 一个环节
用来 记录 decision
那个 面板 是一个 什么？ 一个 MD 么 ？
有些决策会被推翻，但是我发现llm agent有时候对否定助词并不敏感，只要你提到某个技术，它就会想当然的用上。
所以，与其说”我们决定不用kubernetes，使用fargate ecs"，我干脆就不提kubernetes，直接给后续的agent最终决定”我们用ecs fargate"
如果真的需要这些历史信息，那就用git commit history来考古
可能 最后 历史上下文 多了 还是得用 git 来管理， 但是 我现在觉得 都 一个 MD ，对人来说 友好一些
Claude code ， 连客户点一个赞 都要 感谢一下。。。
感觉就像小孩，别说“不要如何如何”，越说越会去做
奇怪， 我以前理解 IT 系统对 这种 不要 什么的 应该特别敏感，应该是当成底线的
以前是 program 逻辑，写死了就是写死了。现在是相关性权重，你只要提到了不论喜不喜欢禁不禁止都会加大权重。
比如你要它开灯，要求“拉开关线，千万别碰铜片”，第一次它是记得的。但下一次你说开灯的时候，没有强调这句话，很难确保它是拨铜片还是拉线。
所以，最佳策略就是马工提到的，你的指令就是“拉线”即可，不要提到“铜片”。
这就是ai玄学
你要是问我要证据证明llm确实有这个特征，我也拿不出证据
但是经验告诉我，这样做有效
[强]
不是玄学啊，做测试是能够证实的。虽然是概率，但确实权重被上下文修改了。
这种测试现在不难了，搞一个小模型自己机器上都能跑。
应该有论文了
那我把 这个 加到 way of working 里面去 ，让他自己给自己写prompt 时 ，尽量用 肯定的方式 和提供一些明确的方向
确实有论文提到多用肯定方式 prompt，少用负面指令。
这种事 负面 教材 对不 ？
Control the format of responses
There are a few ways that we have found to be particularly effective in steering output formatting in Claude 4.x models:
Tell Claude what to do instead of what not to do
Instead of: "Do not use markdown in your response"
Try: "Your response should be composed of smoothly flowing prose paragraphs."
哈哈， 确实和教小孩 差不多
但是 instead of 也算 一个 负面 prompt 对不
nagation都不太好
用 comment 方式 和 CC 沟通 东西 还挺 方便的
兄弟们。。我去冲了ProductHunt。。欢迎帮忙转发顶顶，看看有没有新流量https://www.producthunt.com/products/huan-ai-talent-flow
你还真不谦虚，直接用自己的名字命名了产品
[捂脸]
哈哈哈 有点炼丹的感觉了 需要老师傅
5天，用了估计7亿左右的token。
Cursor 3.4亿，CC没看估计差不多[破涕为笑]
挺猛的。一个人吗？也费人脑token吧
[强][强][强]
欢爱智能，哈哈
一个人啊，其实还没放开用。工作量不满，不少时间都用在搭环境了，还有CC动不动就不能用