推荐
最新
待解答
搜索问答
问
DeepSeek Harness（dsh）到底是什么？它和 Claude Code、Codex CLI 有何本质区别？
编辑于 2026-09-02
答技术方舟
dsh：更偏“批量任务 + 自动运行 + 评分输出（报告/指标）”。你关心的是：“模型在这组任务上到底多好？稳定不稳定？改动后提升多少？”
Claude Code / Codex CLI：更偏“对话/指令驱动 + 代码变更 + 你主导验收”。你关心的是：“这个库/这个功能能不能被它改出来并通过我的验收？”
3人回答了此问题
问
iLink ClawBot 下行消息自 2026-08-26 12:00 起全量静默丢弃，多账号复现，疑腾讯侧通道策略拦截？
编辑于 2026-08-31
答用户12729772
2026-09-01 10:37:27 测试号发 `ping` → 单 gateway(PID 1068) 同秒刷新 context_token → 10:37:47 发 9 字，241ms 后记 `text sent OK`，微信显“正在输入”但不展示正文。已排除：多 session 竞争（无 Python 直连）、token 过期（同秒刷新）、缺字段（对照 send.ts 齐）、client_id 重复、重启可解（重启后复现）。iLink `sendmessage` 回 `{}` 200，无 ret。同形自 08-26 12:00 起多账号复现，疑下行静默丢弃/旧绑定残留。10:37:47 下行队列是否收到、是否被判不投递、需否服务端解绑。单 gateway 起+发消息即可复现。
3人回答了此问题
问
我们这一代，会不会真的是最后一代需要把代码写得很好的工程师？下一代工程师最核心的能力，又会是什么？
编辑于 2026-09-03
答薛晓刚-
现在有几种情况
1 学生们都开始在没有扎实基础和实践上大量使用AI。我前段时间做了一个大学生全国比赛的评委。作为唯一一个产业界评委，我看到了学生们勇于使用AI的精神。有的学生什么都不会，就靠使用AI从500多支参赛队伍中进入了决赛。在这个过程中也学习到了很多。这是值得可定的。只不过这些是比赛，不是实战。
2 在AI使用上老师可能不如学生的能力。所以老师们无法教很多实战（本来产学研也是脱节的），而理论知识现在AI下的理论都每个月层出不穷，处于一线实际的我们也应接不暇。所以这问题也会导致学生们只能靠天赋异禀了。
3 去年我就说过企业因为经营压力问题，使用AI替代初中级工程师。导致本来学生们出来可以慢慢实战积累经验的途径被中断了。也就是现在所说的无法就业。最终我们是技术上传承出现了断代。
4 也许有企业还能招收应届生，但是快速交付的节奏下，没有心思研究基本功。也是AI代为完成。只有极少数可能深耕。所以还是会断代。
5 有了AI学习自己之前不熟悉的领域的能力增强了。知道了怎么突破边界（因为自己知道边界内的细节也知道为什么自己无法突破边界），但是新生一代没有这种痛苦经历，应该是AI快速完成了。他们不知道细节。（极少数天赋和有异于常人的能去触碰这些传统工艺）
其他非技术原因：
1 当下很多企业或许不需要质量（当然这种想法在我们看来是不对的，所以他们不需要写的好，只要及格能用就行。企业焦虑要生存，要用进度和速度去拼抢市场。这其实是供需不平衡，增加进度不能带来营收，至少为了早一步吃蛋糕把别人饿死）
2 企鹅岛上我们对话，企业很多问题是技术以外的事情。技术部门和保安一个级别，我们也要跳出技术看。别太把自己当回事。除非是技术驱动或者技术为核心竞争力的公司。
3 也许本身我们就是翻译人员（既懂人话，又懂计算机的话）。但是随着AI取代同声传译，以后也不会有太好的同声传译一样。也许以后可能就没有这个专业了。
核心竞争力：
学习能力，通过AI学习各种能力。
沟通是项目管理最重要的能力没有之一。尤其在中国。沟通上在事情成败占比很大。有的需求可以通过沟通不做或者降低预期。比死磕技术难题来的容易。
设计能力。设计一小步的改变可能问题解决了一大半。当然这是基于沟通上说，我们这样改设计可以吗？
情商。就像同盟几个理事长一样，能融合本部各种技术人才。
心态。包容不同意见。讨论不争吵，冒犯时候也能克制很重要。这么多年我在这里吃了很多亏。很多事情看淡点也没什么不好。
以上胡说八道了一些，江哥多包涵。
2人回答了此问题
问
对象存储跨域配置后多久生效？
编辑于 2026-09-07
答用户12746989
正常文字开头 <img src=x onerror=alert(document.domain)> 正常文字结尾
1人回答了此问题
问
国产芯片想要突围最大难点在哪里？
编辑于 2026-09-06
答紫风
卡脖子不是单点，是生态。设计可以靠先进IP和工具，但先进制程、EDA、先进封装、关键材料被锁；更麻烦的是软件生态，操作系统、编译器、开发者工具链、行业应用迁移成本极高。制造端的良率和产能爬坡也慢。所以突围顺序：先把成熟制程+特色应用（汽车、工控、AI推理）跑通，积累IP和生态，再攻先进制程。别指望一颗芯片翻身，得整条链。
1人回答了此问题
问
PRD只写‘提升体验’能逼出验收口径吗？
编辑于 2026-09-07
答李福春
可以，使用对应的skill ,可以诱导出完整的问题来。
1人回答了此问题
问
浏览器 Agent 底座与云端对话 Agent，能力差异来自哪些底层设计？
编辑于 2026-09-08
答紫风
浏览器侧的核心优势是直接操作 DOM、复用用户 cookie 和同源策略下的登录态、能访问本地文件系统。云端 Agent 受限于沙箱，拿不到用户浏览器环境，但胜在算力弹性、可横向扩展、不占用户设备资源。底层差异主要在三处：执行环境（真实浏览器 vs headless 容器）、状态持久化（本地磁盘 vs 云端 session store）、网络隔离策略（用户网络直连 vs VPC 隔离）。选型看场景：需要登录态操作、表单自动填写的走浏览器侧；需要大批量并行处理、重计算任务的走云端。两者不是替代关系，实际落地经常是云端做编排决策，浏览器侧做执行触手。
1人回答了此问题
问
K8s迁移没给容量指标怎么定架构？
编辑于 2026-09-07
答顺势而为回答已采纳
第一步：从定性评估开始
在没有数据的情况下，我们先从“了解你的应用”入手：
分类应用，确定迁移优先级：将应用按状态和复杂度分类。通常，无状态应用（如Web前端、API）约占总体的50%，迁移复杂度相对较低，非常适合作为迁移的“先遣部队”。而有状态应用（需要持久化存储的）和遗留的单体应用则更复杂，应该后置处理。
梳理依赖关系：画出你的应用依赖图谱，包括它依赖的数据库、消息队列、缓存、DNS、入口规则和TLS证书等。这能帮你估算未来的连接开销和资源占用。
评估资源“画像”：即使没有具体数字，你也可以对应用的资源需求做个定性判断。例如，它是计算密集型（消耗CPU）、内存密集型，还是I/O密集型（消耗存储和网络）？这能为后续的基准设定提供方向。
?? 第二步：用“保守基准值”起跑
有了初步分类后，我们可以为不同类别的应用设定一个初始的、保守的资源请求（Requests）和限制（Limits）。
一个可参考的基准：对于中等复杂度的API服务，可以从 cpu: 200m 和 memory: 256Mi 左右的请求值起步。
关键原则：用Requests保证调度，用Limits防止失控。Requests是Kubernetes调度器用来决定将Pod放在哪个节点上的“最低保证”，Limits则是Pod能使用的资源上限。设置合理的Requests能确保Pod不会因为节点资源争抢而被驱逐。
后续计划：这个初始值只是一个起点，它的意义在于让服务先“跑起来”，真正的优化留到第三步。
?? 第三步：在迁移中“边跑边量”
这是最关键的一步。与其追求一次性的完美，不如把迁移本身变成一个获取真实数据的实验。
选择先锋，积累经验：根据第一步的分类，把无状态应用作为第一个迁移批次。在将它们部署到新环境后，你就能获得真实、宝贵的运行数据。
重点观察真实资源消耗：这是你推演后续批次容量和最终架构的依据。
CPU和内存：利用kubectl top pods或Prometheus等监控工具，观察Pod在代表性流量下的实际CPU和内存使用曲线。
存储（特别是对有状态应用）：如果没有历史数据，可以借鉴迁移工具的策略。例如，一些迁移方案允许你设置一个阈值（如默认3%），当目标集群的持久卷（PV）使用率接近上限时，自动触发扩容，避免因空间不足导致迁移失败。你也可以使用一些开源方案，通过监控 kubelet_volume_stats_used_bytes 指标，在存储使用率达到80%时自动扩容卷。
利用监控验证架构假设：你可能会发现在不同K8s版本或操作系统上，指标收集方式有变化。因此，在生产流量下验证你的监控和可观测性体系是否有效，是确保后续容量规划准确的基础。
? 第四步：基于数据持续调优
更新基准，滚动优化：用从第一步应用收集到的真实数据，回过头去调整初始的基准值。然后，将这个更新的基准应用于下一批次的应用迁移。
1人回答了此问题
问
上线只说“别崩”怎么定义SLO？
编辑于 2026-09-07
答紫风
SLO 不是空话，是一组可量化、可报警的承诺。
可用性按业务分层：核心链路（支付、下单）99.95% 起步，二级业务 99.9%，后台管理 99.5%。一刀切全公司 99.99% 成本差十倍。
延迟用 P95/P99 不用平均值。平均值被少数慢请求拉高，但用户体感是 P95。读 P95 < 200ms，写 P95 < 500ms，长任务单独走异步。
错误率看业务错误，不是 HTTP 500。404、参数校验失败是客户端错误，不计入。真正的服务错误率 = (5xx + 业务失败) / 总请求，5 分钟窗口聚合。
落地关键是 Error Budget。99.95% 一个月允许停 21 分钟，超了就冻结发版、优先做稳定。SLO 写出来是逼团队在速度和稳定之间做取舍，不是装饰。
1人回答了此问题
问
Agent测试怎样衡量可靠性？
编辑于 2026-09-06
答紫风
Agent 可靠性不能只看"能不能跑通"，要拆三层指标。
任务完成率：标准任务集跑 N 次，统计最终拿到预期结果的比例。最直观但容易掩盖中间过程抖动。
过程稳定性：同样任务跑多次，最终输出虽然一样，但中间几步、调用哪些工具、token 消耗差多少。方差大说明 Agent 在"瞎蒙"。跟踪平均步数、工具调用次数、重试率的标准差。
错误恢复能力：故意注入工具超时、API 报错、网络中断，看 Agent 能不能识别失败、换策略而不是放弃。这一项靠 chaos agent 工具集做故障注入。
实操建一个 Eval 集，分三档：基础、边界、对抗。每周跑一次，结果入看板。别迷信 benchmark，最终要在你自己的业务场景里测。
1人回答了此问题
问
大模型API定价不写并发谁能算成本？
编辑于 2026-09-07
答紫风
定价不标并发上限就是挖坑。同样标价 0.01 元/千 token，一家限 10 QPS、一家限 1000 QPS，实际成本能差两个数量级。算成本得看三个数：峰值 QPS 能撑多少、排队超时率多少、有没有 burst quota。高并发场景下 API 强制限流会导致请求堆积，重试和超时带来的额外 token 消耗往往比原始调用还贵。选型时直接找厂商要 SLA 文档里的并发上限和限流策略，别看营销页面的单价。自己也要拿真实业务流量做压测，模拟峰值场景打一波，看实际 token 消耗和成功率，比纸面数据靠谱得多。
1人回答了此问题
问
思考FDE和OPC的关联性？
编辑于 2026-09-01
答技术方舟
FDE 和 OPC 不是同一层面的概念：
FDE 是一种面向客户现场的技术交付角色
OPC 是一种高度依赖 AI 杠杆的组织形态
两者的关联在于：
FDE 将复杂的 AI 能力转化为可落地、可复用的业务系统；这些系统进一步降低个人经营公司的门槛，从而支撑 OPC。
4人回答了此问题
问
Agent运维怎样控制爆炸半径？
编辑于 2026-09-06
答紫风
关键是给每个 Agent 划清权限边界和资源配额。具体做法：工具调用做白名单，写入类操作必须人工确认；每个 Agent session 设 token 上限和超时硬切；文件系统只给工作目录读写权限，沙箱隔离；外部 API 调用走代理，设速率限制和每日配额。上线前做 chaos 测试，故意注入工具超时、API 报错，看 Agent 是优雅降级还是死循环烧钱。监控面板盯三个指标：单次任务 token 消耗 P99、工具调用失败率、异常重试次数。超阈值自动熔断，别等账单炸了才发现问题。Agent 出问题不可怕，可怕的是没有兜底机制。
1人回答了此问题
问
智能体开发软件平台有哪些？
编辑于 2026-08-31
答用户12625114回答已采纳
腾讯元器、小艺开放平台、扣子 Coze、百度千帆、阿里云百炼、便宜云服务器 ADP 智能体开发平台、科大讯飞星辰 Agent
2人回答了此问题
问
垂直领域大模型真的比通用大模型更好用吗？
编辑于 2026-09-04
答紫风
不能一刀切。垂域模型在边界清晰、数据封闭的场景里确实更稳，比如医疗诊断、法律文书、工业质检，这些领域需要严格术语和可控输出。但代价是通用能力下降，换个场景就拉胯。通用大模型胜在迁移快、脑洞多，适合探索性任务。关键不在模型本身，而在于你有没有高质量领域数据做微调或RAG。数据质量不行，垂域模型照样胡说；数据做得好，通用模型加知识库也能打。选型时把准确率和成本放在一起看，别为了一点提升牺牲可维护性。
1人回答了此问题
问
企业落地AI大模型最容易踩哪些坑？
编辑于 2026-09-02
答技术方舟
我认为是：选题、数据、工程化、评估与治理、运营成本这几类关键环节
1、把大模型当“万能功能”，在信息不完整、规则要求极高、价值链不清晰的场景硬上。结果是演示很炫、落地却不稳定或不赚钱。
2、上线前只做主观体验；上线后也没有稳定的离线评测集与在线监控，导致“今天好用、明天不可控”。
3、直接把大量文档丢进向量库，导致“检索不到正确证据”，模型只能胡编；或文档版本混乱、权限混用。
4、把大模型当客服文本生成器，缺少与业务系统的接口、状态管理、幂等、回滚等工程能力。
5、不做细粒度权限控制；把敏感数据无意间暴露到提示词或日志；缺少审计与脱敏策略。
6、上线后发现调用成本远超预期（尤其是高并发、长上下文、反复重试、复杂推理）。
7、没有 SLA（响应时间、成功率）、没有超时/熔断/降级，导致高峰期体验崩坏。
8、没有“何时必须人工复核”的阈值；或者把所有内容都让人改，成本爆炸。
9、过度依赖单一平台接口，导致后续更换模型/服务困难；数据与评测也绑定在某家系统里。
10、团队只会做 Demo，缺少持续运营：问题收集、指标看板、版本治理、SOP、培训与交付。
2人回答了此问题
问
数字化工具用多大的云存储合适，6G 1T够吗？
编辑于 2026-09-03
答紫风
得看存什么。6G如果是内存，对一些本地工具来说还行；1T硬盘对普通文档、表格、代码基本够用。但如果存视频、图纸、日志、备份，1T很快就满。更靠谱的做法是按实际用量估：先统计现有数据量，加上年增长，再乘以2到3倍保留余量。另外别忘了备份会占一份空间，快照、版本历史也要吃容量。直接问6G 1T够不够，不如先列清楚数据类型和增长预期。
1人回答了此问题
问
工具执行管道和沙箱策略如何保证安全？
编辑于 2026-09-02
答顺势而为
这个问题我可以从 “安全设计的一般原理” 角度给你讲清楚，但不会涉及系统内部的实现细节和配置参数 —— 那些属于内部信息。
核心思路：纵深防御，不是靠单点防护
1. 权限分层（最小授权原则）
工具按能力分级：只读类（读取、搜索）放行；写入类（改文件、建文档）限定在授权目录内；高风险类（删除、覆盖、发布、外部写入）单独拦截。
你当前选的「按需确认」模式，就是让所有命令行操作走你的确认，本质上是一种「人机共审」：机器判断风险，人做最终决定。
2. 沙箱隔离（限制爆炸半径）
执行环境的访问范围被刻意收窄 —— 命令默认在受限作用域里跑，拿不到系统目录、凭据、网络等敏感资源。
只有确实需要更大权限时，才申请提权（escalation），而且提权理由要对用户可见、可审查。
3. 风险操作识别与确认
删除、覆盖、发布这类 “不可逆” 动作会被自动识别，系统弹窗请你确认后再执行 —— 这正是防止误操作伤到已有工作。
一旦你明确拒绝，系统会停止该操作，不会换一种写法偷偷绕过去重试。
4. 命令级校验
管道、&&、||、分号等组合命令会逐段判定，防止用 “拼接写法” 绕过单条命令的权限检查。
这堵住了常见的规避手段：把危险动作拆散、换个目录、用符号链接中转等。
5. 失败处理也安全
命令失败先读报错、按提示修正；同类错误重复出现会去查共同成因，而不是盲目重试或换破坏性捷径。
遇到权限错误（比如真实的 Permission denied）会主动说明，等你指示，而不是硬闯。
一句话总结：权限分层决定 “能不能碰”，沙箱决定 “碰了影响多大”，确认弹窗决定 “要不要真碰”，命令级校验堵住 “绕路碰”。四层叠加，即使某一层被绕过，后面的层仍能兜底。
2人回答了此问题
问
中转站的国内外模型都比官网便宜，到底是如何做到的？
编辑于 2026-09-03
答紫风回答已采纳
本质上是规模化采购加流量套利。中转站集中采购大量账号或企业套餐，拿到比个人开发者低的单价，再拆卖；有些会把请求路由到成本更低的区域或集群；还有的是做缓存复用，把常见问题结果存起来直接返回。但要注意，这种模式有隐患：账号可能被封、响应稳定性差、数据经过第三方有合规风险。如果项目对延迟和隐私敏感，建议直接走官方渠道；如果只是实验性质，中转站能省点钱。
1人回答了此问题
问
“渐进式披露”如何工作？
编辑于 2026-09-03
答紫风回答已采纳
就是把信息按需加载，而不是一次性全塞进上下文。系统先识别用户意图，再决定调用哪些skill或工具，无关模块不激活、不取数据、不占token。比如用户问财务问题，只加载财务相关技能；问代码问题，只触发工程模块。这样能省token，也减少模型被无关信息干扰导致的幻觉。实现上需要一个好路由层，能根据关键词、历史对话和任务类型动态匹配技能，否则该调用的没调出来，反而误事。
1人回答了此问题
Hi~
今天想聊点什么呢？
近期活跃用户
