有谁一起参加黑客松！！！
有一定的vibecoding基础的一起来
细思，Muse 确实有做成新时代微信的机会。
微信当年最重要的功能，是给人发消息，同时比短信还便宜非常多。想发消息的人在微信上，带来用户吸引，形成了网络效应。有用 + 网络效应 + 运气，成就了微信。不是因为微信有多懂你。
Muse 能帮人处理邮件日历、电话催单等各种杂事，这有点像微信最开始的发消息。Muse 的网络效应会在哪。没有网络效应的话，和 ChatGPT 会是同质化竞争。豆包在国内活成了新时代的百度。
Meta 真正的杀招，可能是 WhatsApp -〉 Muse，类似当年的 QQ 通讯录 -〉 微信。不仅自己的 Muse 能干活，而是我的 Muse 还可以连接 WhatsApp 关系网中的其他人的 Muse，彼此因连接而强大。如果 Muse 敢往这个方向发展，则就有机会构建网络效应。而且会比微信更厉害：微信通过手机，让人醒着就在线。Muse 通过 agent，让人睡着也在线。
有用 + 有机会构建网络效应，最后就只欠运气了。不期待小扎有这个运气，不期待任何大厂有这个运气。只期待齐俊元、肖弘、玉伯、马小龙、赵小兰等创业者有这个运气。
有意思的时代，正在开启。
80％的代码都是AI写的，公司为什么还需要你？
这个问题越来越高频
先说一个事实：2026 年的技术面试，已经和两年前完全不一样了。
两年前面试问的是："手写一个 Promise"、"说说 React Fiber 原理"、"浏览器渲染流程是什么"。
现在面试官默认你会用 AI。他们真正想知道的是：在 AI 能写代码的时代，你的不可替代性是什么？
我在技术社群里问了一圈，今年至少有三种问法：
"AI 能写 80% 的代码了，你的价值在哪？"
"如果我给你一个实习生 + Claude Code，能替代你吗？"
"你和 AI 的分工是什么？"
本质上是同一个问题。答不好，直接挂。
大多数人的回答，都踩了坑
我收集了一些常见回答，面试官听完基本都不满意：
❌ 回答一："AI 写的代码质量不行，还是需要人来写"
这个回答在 2024 年还行。2026 年不行了。
Claude Code 和 Codex 生成的代码质量已经相当高，大部分 CRUD 接口、表单组件、工具函数，AI 写得比很多初级开发者还好。你说"AI 代码质量不行"，面试官心里想的是：那是不是说明你的水平和 AI 差不多？
❌ 回答二："AI 不理解业务需求"
面试官会追问："那产品经理把需求写清楚，AI 不就能理解了？"
你会发现自己很难反驳。因为事实是——大部分需求确实可以用自然语言描述清楚，AI 确实能根据描述生成代码。
❌ 回答三："总需要有人来做 Code Review"
这个回答把自己定位成了"AI 的质检员"。面试官会想：质检员的工资不需要两万。
我后来怎么回答的
被问了四次之后，我想明白了一件事：这个问题考的不是你对 AI 的态度，而是你对自己价值的认知。
我现在的回答分三层：
第一层：AI 写的是代码，人做的是决策
"AI 能写 80% 的代码，但它写不了那 20% 的决策。"
举个具体的例子。上个月我们做一个电商活动页，需求是"用户下单后展示倒计时"。
AI 可以完美地写出一个倒计时组件。但它不会问你这些问题：
倒计时结束后，用户页面还停着怎么办？自动刷新还是弹窗提示？
如果用户修改本地时间，倒计时会不会被绕过？
高并发下，几万人同时倒计时归零，后端扛得住吗？前端要不要做请求排队？
这个倒计时需要和服务端时间同步吗？客户端时间不准怎么办？
这些问题，每一个都可能导致线上事故。AI 不会主动想到它们，因为 AI 只解决"你提出的问题"，不解决"你没想到的问题"。
高级开发者的价值不是写代码，是知道哪些代码不该写、哪些场景会出事、哪些决策会影响未来半年的维护成本。
第二层：AI 能写一个文件，人能设计一个系统
"AI 是一个极其优秀的执行者，但它没有系统视角。"
让 Claude Code 写一个用户注册接口，它能写得很好。但让它设计整个用户系统，它不知道：
注册和登录要不要拆成两个微服务？
用户数据怎么分库分表？按 user_id hash 还是按注册时间 range？
Session 用 JWT 还是 Redis？各有什么取舍？
未来要接第三方登录（微信、Google），现在的表结构要不要预留扩展字段？
这些是架构决策，需要结合业务规模、团队能力、技术栈现状、未来规划来综合判断。
AI 可以给你列出 5 种方案，但它不知道哪种方案适合你的公司。这个判断，只有人能做。
我面试时说了一句话，面试官听完点了头：
"AI 让写代码的门槛降低了，但让做正确决策的门槛提高了。因为现在代码生成太快了，做错了决策会比以前更快地变成一大堆技术债。"
第三层：AI 不能对结果负责
"出了线上事故，AI 不会被 oncall 叫起来。"
这一层听起来像玩笑，但它是最本质的。
代码部署到线上，半夜三点告警了。需要有人：
判断影响范围
决定要不要回滚
协调前端后端运维多方排查
在半小时内给出修复方案
事后写复盘报告，推动流程改进
这些事情，每一件都需要判断力、沟通能力、责任心。AI 可以帮你查日志、分析堆栈，但它做不了决策，扛不了责任。
公司花两万月薪招你，不是在买你写代码的时间，是在买你的判断力和责任心。
面试官真正想听到的
总结一下。这个问题的正确答案结构是：
层次 核心观点 一句话
执行层 AI 写代码，人做决策 AI 解决你提出的问题，但不会发现你没想到的问题
架构层 AI 写文件，人设计系统 AI 能列方案，但不知道哪个适合你的公司
责任层 AI 不能被叫起来修 bug 公司买的不是代码，是判断力和责任心
最后补一个加分动作：给一个真实案例。
不要泛泛而谈"AI 不行"。讲一个你亲身经历的场景：
"上个月 AI 帮我写了一个数据导出功能，跑得很好。但我 review 的时候发现它没有做分页——10 万条数据一次性加载，在测试环境没问题，到生产环境直接 OOM。这种问题 AI 不会意识到，因为它不知道你的生产数据量有多大。"
一个具体案例胜过十句正确的废话。
AI 时代前端的核心竞争力
如果你还在纠结"要不要学 AI"，这个问题本身就问错了。AI 是工具，不是竞争对手。
真正应该问的是：什么能力是 AI 越强，人越值钱的？
系统设计能力 — AI 生成代码越快，做错设计的成本越高
业务理解能力 — 理解需求背后的"为什么"，而不只是"做什么"
跨团队协作 — 协调前后端、产品、设计，这不是写代码能解决的
线上兜底能力 — 出了事能扛住、能查出来、能修好、能防住下次
这四项能力，AI 越强，越稀缺。
最后
下次面试再被问"AI 能写代码了你还有什么用"，不要慌。
这个问题不是在质疑你，而是在给你一个展示高阶思维的机会。能把这个问题答好的人，恰恰是 AI 时代最值钱的人。
你面试时被问过类似的问题吗？你是怎么回答的？评论区聊聊。
这两年一直致力于公司的Agent开发。总结了一些思考和解决方案，今天给大家分享下，也是给自己的一个复盘。
做 Agent 最有意思的是，通常是 Demo 刚跑通的那一下：模型理解了需求，自己选了工具，还给出了看起来不错的结果。
真正让人头疼的是，是第二个阶段。
用户换了一种问法，状态丢了；工具返回一个含糊的错误，Agent 开始乱试；你改了提示词，一个场景好了，另一个场景坏了；上线第二天，账单和延迟一起超预期。
所以，Agent Demo 和 Agent 系统之间，隔着一层工程问题。这就是通常所说的工程化解决方案
这层问题不是换框架能解决的。框架解决的是调用模型、注册工具、组织消息这些胶水层；真正难的是下面五件事：
状态怎么传？
工具怎么约束？
错误怎么恢复？
效果怎么回归？
延迟和成本怎么控？
LangChain、LangGraph、Spring AI、AgentScope 或自研循环，这些都是我们去做一个agent的基本框架，工程化的问题，他们依然存在。
可能这里有人嘴犟了，推出市面上一些比较好的开源框架 比如字节的deerflow，这个我们公司也在用，的确把一些基本上工程问题化解掉了，但就像你做springboot、cloud开发一样。你要知道怎么解决实际业务问题，实际的业务开发才是硬道理。
今天这篇文章带你从难点展开。每一节都先讲麻烦在哪里，再给可落地的解法。不管你是否搞过agent开发，都能明白。（多说一句，不用在乎什么语言，不管是Python、亦或是Spring ai生态，其实都是一致的，我们需要掌握的是解决思路与方案）
一、上下文：难在状态会丢
首当其冲肯定是上下文，上下文的难点：不是写 Prompt;
假设我们要做一个“汽车门店销量助手”。
用户先问：“帮我看看上海上周的销量。”
下一句又问：“那杭州呢？”
人一听就懂：用户要查“杭州上周的销量”，继承“上周”和“销量”，只把“上海”换成“杭州”。
但如果系统只把最后一句“那杭州呢？”传给模型，模型就不知道该查销量，更不知道时间范围是上周。
很多人的第一反应是把更多资料塞给模型。这样做短期有效，长期会引入三个问题：
状态丢失：用户说“换成上周”“再看另一个对象”，关键信息在历史对话里，不在当前输入里。
状态冲突：系统提示说只能查最近 30 天，历史里还有用户之前查过的去年数据。
重点稀释：工具返回、检索片段、执行日志全部塞进上下文，模型反而找不到关键约束。
Agent 的上下文不是一个聊天记录列表，而是一个随任务推进不断变化的运行时状态。
正确做法类似 Java 里的领域对象：维护一个明确的查询状态。
class SalesQueryState {
private String city = "上海";
private LocalDate startDate = LocalDate.of(2026, 9, 14);
private LocalDate endDate = LocalDate.of(2026, 9, 20);
private String metric = "sales";
}
用户说“那杭州呢”，只更新一个字段：
state.setCity("杭州");
不要把整个对象重建，也不要让模型随意覆盖所有字段。
一个实用的上下文结构是：
State 当前任务状态：城市、时间、指标
Evidence 本次回答需要的证据：销量数据、报表片段
History 最近几轮对话，用来理解“那杭州呢”
一句话：程序维护状态，模型解析意图。
落成流程就是四步：
模型读取最近对话 + 当前状态，输出结构化意图
程序校验城市、日期、指标是否合法
只合并允许变化的字段
用新状态去查数据 对应 Java 大概是：
QueryIntent intent = llm.parseIntent(history, state, "那杭州呢？");
if (!cityRepository.exists(intent.city())) {
throw new InvalidCityException(intent.city());
}
state.apply(intent); // 只改 city，保留时间和指标
二、工具：难在把概率系统接到确定性接口上
工具调用看起来只是让模型调用函数，麻烦在失败场景。
比如模型调用：
querySales("魔都", lastWeek);
系统可能遇到：
魔都不是标准城市名
日期算错
查询结果为空
接口超时
用户没有权限
如果工具只返回字符串：
String querySales(String city, DateRange range);
模型分不清空结果、参数错、超时和权限问题，只能靠猜。
比如可以像设计 Java 接口一样设计工具契约：
record ToolResult(
Status status,
Map<String, Object> data,
String message,
boolean retryable,
String nextAction
) {}
enum Status {
SUCCESS, EMPTY, INVALID_ARGUMENT,
PERMISSION_DENIED, TIMEOUT
}
城市名错误时返回：
new ToolResult(
INVALID_ARGUMENT,
Map.of(),
"city 不是标准城市名",
true,
"调用 resolveCity，把魔都解析成上海"
);
这样程序知道能不能重试，模型知道下一步该做什么。
工具层还要做三件事：
参数校验：城市、日期、范围在工具层强制检查
幂等：下单、发消息、删除数据必须带幂等键
权限分级：只读、可逆写、不可逆写分开处理
一句话：不要指望 Prompt 保证安全，接口必须能挡住错误。
写工具时可以直接套这个模板：
ToolResult querySales(String city, DateRange range, User user) {
if (!permissionService.canReadSales(user, city)) {
return ToolResult.denied("无权限查看该城市销量");
}
String normalizedCity = cityService.normalize(city);
if (normalizedCity == null) {
return ToolResult.invalidArgument(
"城市名不标准",
"请先调用 resolveCity"
);
}
if (!dateService.isValidSalesRange(range)) {
return ToolResult.invalidArgument("日期超出可查范围", "请改成最近90天");
}
List<SalesRow> rows = salesRepository.findByCityAndRange(normalizedCity, range);
if (rows.isEmpty()) {
return ToolResult.empty("查询成功但没有数据", "不要编造趋势");
}
return ToolResult.success(rows);
}
重点是顺序不能乱：
先权限，再参数，再查询，最后处理空结果和异常。
三、执行：难在 Agent 越跑越偏
没有边界的 Agent 很容易这样跑：
第 1 步：查上海销量
第 2 步：查杭州销量
第 3 步：发现杭州门店数据异常
第 4 步：跑去查库存
第 5 步：又查了一遍上海
第 6 步：宣布任务完成
用户只是想比较上海和杭州上周销量，Agent 却发散到库存，还重复查询。
解决方案不是让模型“更认真”，而是给它一个有限任务图：
ClarifyIntent 明确城市、时间、指标
ResolveCity 处理城市别名
FetchSales 查询销量
Analyze 对比结果
GenerateResult 生成回答
ConfirmResult 验收
类似 Java 状态机：
if (state == RESOLVE_CITY && cityValid) {
state = FETCH_SALES;
}
再加上预算：
最多 2 次销量查询 最多 1 次城市解析 最多 1 次重试 总耗时不超过 10 秒 最后由程序验收：
boolean acceptable =
result.contains("上海")
&& result.contains("杭州")
&& result.timeRangeIs(lastWeek)
&& result.referencesToolData();
不要相信“模型说完成”。
一句话：模型负责决策建议，程序负责边界和验收。
可以直接落成三个对象。
第一，节点定义：
enum Node {
CLARIFY_INTENT,
RESOLVE_CITY,
FETCH_SALES,
ANALYZE,
GENERATE_RESULT,
CONFIRM_RESULT
}
第二，预算控制：
class TaskBudget {
private int llmCalls;
private int toolCalls;
private int retries;
boolean allowToolCall() {
return toolCalls < 5;
}
boolean allowRetry() {
return retries < 2;
}
}
第三，验收器：
class SalesResultValidator {
boolean validate(SalesQueryState state, AgentResult result) {
return result.cities().equals(state.cities())
&& result.range().equals(state.range())
&& result.metric().equals(state.metric())
&& result.allNumbersHaveSource();
}
}
如果验收失败：
第一次：把失败原因交给模型修复
第二次：降低任务范围
第三次：转人工或返回失败原因
四、评估：难在不知道错在哪一步
Agent 最后回答：
杭州销量比上海高 18%。
这个结论可能错在四层：
意图层：用户问门店销量，Agent 查了城市总量
工具层：只查了杭州，没查上海
数据层：把上周日期算错
生成层：数据是 8%，写成 18%
只看最终答案，无法定位问题。
所以要分层评估：
[
{
"id": "followup-city",
"history": ["帮我
你有没有过这种经历：
让AI帮你写段代码，它写错了。你客气地说“麻烦你再改一下”，它道歉，然后改出了另一个错。
你火了，直接怼它：“你这写的什么垃圾，第3行逻辑是错的，给我重写。”
结果它秒懂，一次改对。
这不是玄学。今天聊一个技术点，叫 Context Window 里的“信号密度”。
AI每次回答你，不是“回忆”你说了什么，而是把你从头到尾所有对话重新读一遍，然后预测下一个字该是什么。
注意关键词：从头到尾，全部重读。
这意味着什么？
意味着你每多说一句废话，都在稀释真正重要的信息。
你客客气气说“麻烦你了”“谢谢”“不好意思再打扰一下”——这些词在AI的预测模型里，权重极低。它们不指向任何具体动作，不包含任何纠错信号。
但你如果说“第3行”“逻辑错”“改成O(n)”——这些是高密度信号，直接锚定输出方向。
大模型处理对话时，会把你的历史消息拼成一个长序列，送进注意力机制。
注意力机制有个特点：它会给每个token分配权重。
当你输入一段话，模型会计算：哪些词对“下一个该输出什么”最关键？
“请”“麻烦”“谢谢”这类社交润滑词，在训练数据里几乎从不出现在“技术纠错”的上下文里。所以它们的注意力权重极低。
而“第3行”“错误”“重写”“O(n)”这些词，在训练数据里高频出现在“修正代码”的场景中。它们一出现，注意力权重直接拉满。
结果就是：AI不是不懂礼貌，是礼貌在它的概率空间里，约等于噪声。
很多人以为对AI越客气，它越“愿意”帮忙。
实际恰恰相反。
你越客气，信号越稀疏，AI越容易跑偏。你越直接、越具体、越像在写bug report，AI越准。
这不是让你当粗人。这是让你把AI当编译器，不是当人。
你不会跟编译器说“麻烦您帮我编译一下，谢谢”——你直接 gcc -o output source.c。
对AI也一样。
有用。但只在一种情况下有用：
当“请”本身携带了额外信息的时候。
比如“请用Python重写”和“用Python重写”——这里的“请”不携带信息，去掉不影响。
但“请务必不要用递归”和“不要用递归”——“务必”强化了约束强度，这时候它就不是废话了。
判断标准很简单：删掉这个词，意思变不变？
不变，就是噪声。变，就是信号。
一句话总结
AI不读空气，只读token。
你的礼貌在它的注意力机制里，不如一个变量名重要。
下次让它改代码，直接说“第X行，Y问题，改成Z”。
它秒懂。
爬上来说个事，Jev 刷屏快一周了，全网都在吹「新技术路线」。
后台也有不少人问我怎么看？我说句扫兴的：别吹了。
先说下它是啥。前 OpenAI 研究员创业做的模型，最大的特点是不说话，不生成文字，它只帮你做决策。
你给它一段状态加几个问题，它直接返回带概率的判断：选哪个，打几分，有多少把握。
它为什么爆？我说实话，不是因为它强，是它戳中了两个当下 AI 的痛点：token 贵，AI 慢。
拿大模型做分类路由，等于拿大炮打蚊子，烧几百 token 就为了拿回三个 JSON 字段。Jev 输入每百万 token 0.042 美元，输出免费，毫秒级返回。
所以它确实在一些细分场景有用。
比如客服工单一次调用分出部门，紧急度，流失风险，不用等大模型慢悠悠给你写小作文。
比如给大模型当护栏，做模型选择和内容审核。啥活适合什么样的便宜模型，很多人是没有这方面的判断能力的。
比如批量处理文档，实测每千份成本 0.22 美元，DeepSeek Flash 要 1.31 美元。
但别吹成技术突破。能力上和 DeepSeek Flash 打平。
「不会幻觉」是重新定义出来的，OpenAI 的结构化输出，Anthropic 的 tool use 等早就做到了。护城河 48 小时就塌了，推特老哥两小时拿 Qwen 搓出同款，400M 的开源 laya 基本是同款。
能被两小时复现的东西，是工程技巧，不是模型突破。
你要想体验，直接去 GitHub 下载本地部署这个项目：
github.com/NandhaKisho…
所以你要问我怎么看？
Jev 本质上就是一个 JSON 分类器套了层前沿模型的皮。
但是它算是盒合格的止痛药，治的是贵和慢这两个真病。在一些场景上是有需求，但是吹嘘远大于它的能力，X 上一大堆开发者是把它当玩具的。
但是你要拿它当主力出活，做工程，做产品，还是洗洗睡吧。
来找我合作哈哈哈哈哈哈哈，全栈拿捏你的需求