码农戏码

新生代农民工的自我修养

0%

对于Agent的价值,一直抱有怀疑态度,甚至认为未来会不会像大前端一样

别看现在火爆得不行,其实再走到下一个节点,就如前端一样,在裁员批次里面是第一梯队

因为它只是个连接器,一端是大脑LLM,另一端是承载业务的平台或专业软件,它自己本身对业务没有任何承载。

或者说它只是LLM的一个外延,也许未来会有其它的形式

之前想到的一个价值,就类似客服一样,可以帮助客户或者实施更快捷地接入产品,使用产品。

像一个垂直类专业软件,需要花费很多的资源去培训客户,但如果有了agnet,通过自然语言直接对话,都不需要去学习软件的使用,就能产出相应的结果

有点类似后端程序,可能都不清楚产品前端界面是什么样,开发一个个接口逻辑就行了。

但还不够具象。

在看到arthas也出品了agent,这感觉具象化了,对于arthas 我是实实在在的使用客户。

以前你需要去学习arthas的各种命令,会安装一下IDEA 的插件,直接能复制生成出相应完整命令行,再去执行。

但有了agent 那就更方便了,什么都不需要,把碰到的问题直接使用自然语言抛给agent,它能帮你分析,帮你执行命令。相当方便

本来打算学习一下arthas agent,结果agent也没对外开源,只是阿里内部使用。

不过对外开源了mcp server,自己搭agent

https://arthas.aliyun.com/doc/mcp-server.html

1
2
3
4
5
6
7
8
9
10
11
12
13
14
mcp:  
client:
enabled: true
type: sync
name: north-agent
version: 1.0.0
request-timeout: 15s
toolcallback:
enabled: true
streamable-http:
connections:
arthas-mcp:
url: http://localhost:8563
endpoint: /mcp

直接创建一个SKILL.md

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
---
name: arthas-diagnosis
description: 用于 Arthas MCP 诊断任务,包括 JVM 信息查看、线程分析、类加载器排查、方法跟踪、性能采样和文件结果读取。
---

# Arthas 诊断技能

这是面向运行时诊断与排障的专用技能。

## 什么时候使用

- 用户明确提到 `Arthas`、`JVM`、`线程`、`堆`、`类加载器`、`trace`、`watch`、`profiler`
- 用户要做运行时排障、性能分析、线程阻塞分析、类加载问题诊断
- 用户希望读取 Arthas 导出的诊断结果文件

## 核心原则

- 这是诊断域技能,不要和 Lot / CPE 业务操作混用
- 当前环境中的诊断能力来自 **arthas-mcp 已注册工具**,不要假设存在本地 Arthas CLI、`arthas-boot.jar`、JVM attach 权限或 shell 执行能力
- 只能调用当前 skill 已挂载的 MCP 工具;不要编造不存在的工具名,例如 `run_arthas_command`
- 不要读取或引用不存在的示例文件;若用户没有提供真实文件路径,不要假设如 `dashboard_sample_output.txt` 之类的本地样例文件存在
- 先做只读诊断,再做可能影响运行时状态的动作
- 如果用户目标不明确,先澄清要排查的是:线程、内存、类、方法调用、还是性能
- 优先使用风险更低、范围更小的工具

## 可直接使用的工具类型

本技能应直接使用 arthas-mcp 暴露出来的工具,例如:

- 概览:`dashboard`、`jvm`、`memory`、`thread`
- 类诊断:`sc`、`sm`、`classloader`、`jad`
- 方法诊断:`stack`、`trace`、`watch`、`monitor`、`tt`
- 性能分析:`profiler`
- 文件读取:`viewfile`

效果还可以,后面分析一下arthas相关源码,里面的实现很是精巧,有意思!

最近在给排盘软件增加一下神煞的功能

首先神煞命中分成两个太极点:年和日

  • 年取:以年柱为太极点去查
  • 日取:以日柱为太极点去查

然后基本流程是:
1、先确认神煞的查法和作用
2、把介绍、查法和作用都整理输出到文档
3、再根据文档里面的逻辑变成代码逻辑
4、再确认是否展示到UI
5、又增加一项,点击神煞时,会弹出神煞介绍

刚开始手动完成了 三丘五墓、桃花

后来想起这是一套标准动作,以后增加新的神煞时,都需要这么跟AI交互。

这不就是skill吗? 所以就让codex直接创建一个扩展神煞的skill

按这个套路,创建一个 skill,方便后面增加其他的神煞

完成之后,会创建相应的SKILL.md

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
---
name: extend-mingli-shensha
description: Add or update shensha logic in the mingli repo, including rule documentation, utility functions, explanation/method text, and UI display. Use when Codex needs to add a new 神煞, adjust an existing 神煞’s取法 or作用, wire it into src/utils/shensha.ts, update docs/shensha-*.md and docs/shensha-overview.md, or connect it to the App.tsx/App.css display and popup flow.
---

# Extend Mingli Shensha

Implement new shensha in this repo with the same pattern already used for 驿马、桃花、羊刃、禄、天乙贵人、三丘五墓.

## Quick workflow

1. Read `docs/shensha-overview.md` first.
2. If the target shensha already has a dedicated doc, read `docs/shensha-*.md`; otherwise create one before coding.
3. Implement or update logic in `src/utils/shensha.ts`.
4. If the shensha should appear in the UI, wire it into `src/App.tsx` and `src/App.css`.
5. If the shensha needs click-to-explain support, add explanation and method text in `src/utils/shensha.ts`.
6. Run `npm run build` before finishing.

这个skill就叫 extend-mingli-shensha

用这个skill,试一下增加文昌神煞

extend-mingli-shensha to add 文昌的规则、文档和展示

中途不再需要跟AI不停地交互,完整按标准动作完成了整个神煞的整理和开发工作

最后展示的效果也还不错

最近在项目中引入skill

把之前需要在系统提示词中注明的规则,全面挪移到相应skill的 SKILL.md 说明文件中

不过AI迭代太快,Spring Ai Alibaba 文档都来不及更新,里面的bug也不少。

在本地功能测试没有问题,发布到服务器,发现Skill not found: Skill not found: lot-query

1
2
3
4
5
6
7
8

INFO 1 --- [oundedElastic-1] c.a.c.ai.graph.agent.node.AgentLlmNode : [ThreadId 07f735f0-fd80-49b8-b4e5-7e90cfc2eb35] Agent ??? reasoning round 0 streaming output: [ToolCall[id=call_03da1a646a1a410bb82cf6, type=function, name=read_skill, arguments={"skill_name": "lot-query"}]]
2026-03-17T03:01:57.046330027Z 2026-03-17T11:01:57.046+08:00 INFO 1 --- [oundedElastic-1] c.a.c.ai.graph.agent.node.AgentToolNode : [ThreadId 07f735f0-fd80-49b8-b4e5-7e90cfc2eb35] Agent ??? acting with 1 tools.
2026-03-17T03:01:57.048982723Z 2026-03-17T11:01:57.048+08:00 INFO 1 --- [oundedElastic-1] c.a.c.ai.graph.agent.node.AgentToolNode : [ThreadId 07f735f0-fd80-49b8-b4e5-7e90cfc2eb35] Agent ??? acting, executing tool read_skill.
2026-03-17T03:01:57.050245886Z 2026-03-17T11:01:57.050+08:00 WARN 1 --- [oundedElastic-1] c.a.c.a.g.a.hook.skills.ReadSkillTool : **Skill not found: Skill not found: lot-query**
2026-03-17T03:01:57.051826871Z 2026-03-17T11:01:57.051+08:00 INFO 1 --- [oundedElastic-1] c.a.c.ai.graph.agent.node.AgentToolNode : [ThreadId 07f735f0-fd80-49b8-b4e5-7e90cfc2eb35] Agent ??? acting, tool read_skill finished
2026-03-17T03:01:57.053390410Z 2026-03-17T11:01:57.052+08:00 INFO 1 --- [oundedElastic-1] c.a.c.ai.graph.agent.node.AgentToolNode : [ThreadId 07f735f0-fd80-49b8-b4e5-7e90cfc2eb35] Agent ??? acting returned: ToolResponseMessage{responses=[ToolResponse[id=call_03da1a646a1a410bb82cf6, name=read_skill, responseData="Error: Skill not found: lot-query"]], messageType=TOOL, metadata={messageType=TOOL}}

原来是框架里面的ClasspathSkillRegistry 在Spring Boot fat jar 场景中有bug,会加载不到SKILL.md 文件

  1. 打包后的 jar 中已经确认包含 skill 文件,例如:
    • BOOT-INF/classes/skills/cpe-operation/SKILL.md
    • BOOT-INF/classes/skills/lot-operation/SKILL.md
    • BOOT-INF/classes/skills/lot-query/SKILL.md
    • BOOT-INF/classes/skills/true-north-router/SKILL.md
  2. 但应用启动日志显示:
    • TrueNorth skill registry loaded 0 skills.
    • TrueNorth skill registry is empty at startup.
  3. 随后模型调用 read_skill("lot-query") 时,得到:
    • Skill not found: lot-query

使用AI分析了一下源码,现在有AI 学习效率提升不少,以前还要手动翻源码,画流程图,清楚调用关系。

现在先让AI分析一下源码,输出各种结构图,快速梳理出框架主干

再针对性提问题,让他提出源码位置,细节一目了然

把AI分析结果提交个issue: https://github.com/alibaba/spring-ai-alibaba/issues/4426

再让AI重新实现一个SkillRegistry,解决这个问题

项目中有一个参数cpeModel ,是固定的枚举项,希望在大模型询问参数时,给出固定的选项,在
Tool 参数上,描述一下:

1
@ToolParam(description = "必须让用户确认选择cpeModel,可选值只能是CPE2;CPE6;CPE6CF9;CPE15;CPE15CF4;CPE19其中一个") @NotNull String cpeModel

这样就达到了效果,从没有出现幻觉现象。

最近在项目中引入skill,系统提示词大幅减小,却出现了幻觉

模型输出类似:

  • CD65_CPE_Standard
  • CD65_CPE_Advanced
  • CD65_CPE_Quality
  • CPEv2
  • CPEv3
  • CPE-AI

从当前项目代码和 skill 契约来看,这些都不是正式允许值,因此属于幻觉式扩展

这就奇怪,现在的Tool定义上也有,而且在SKILL.md文件中也特意说明

1
2
3
4
5
6
7
8
9
10
11
12
如果用户尚未提供 `cpeModel`,你必须只展示正式允许值列表,并要求用户从中选择。
禁止补充任何额外示例、行业常见名、产品名、历史名、猜测值,禁止使用“常见模型包括”“例如”“或者其他模型名称”这类会诱导扩展的表达。

固定回答格式:

请从以下正式 cpeModel 中选择一个:
- CPE2
- CPE6
- CPE6CF9
- CPE15
- CPE15CF4
- CPE19

虽然这样写了,但有时还是会幻觉,特地还写了一个tool,强制输出枚举项

在SKILL.md里面写上当需要枚举参数确认时,调用这个tool来确认

可过两天测试又正常了,不再需要这个参数确认的tool

最近又有一个新词叫:Harness Engineering

Prompt Engineering管的是「说什么」,Context Engineering管的是「知道什么」,Harness Engineering管的是「在什么环境里做事」

技术上来说,Harness 是包裹在 AI Agent 外面的那层基础设施,负责管理:

  • 工具调用(Tool Use)

  • 上下文记忆(Context / Memory)

  • 错误重试(Retry)

  • 人工审批节点(Human-in-the-loop)

  • 架构约束和代码规范检查

主要就是来应对模型的幻觉和执行的漂移

模型的幻觉
指模型生成内容时,编造出看似合理但事实上错误、无依据的信息。

  • 根源:大模型本质是概率生成器,它在“续写”时没有内置的事实核查机制;训练数据中的偏差、知识截止后的新事实、过度自信的生成都会导致幻觉。

  • 表现:在事实性问答、代码生成、逻辑推理中常见,尤其在模型不确定时反而会“自信地胡说”。

执行的漂移
指在复杂任务(尤其是多步、长周期、与环境交互的任务)中,模型逐渐偏离原始目标、违反约束或进入无效状态。

  • 根源:自回归误差累积、缺乏全局规划、对中间反馈的误判。

  • 表现:例如Agent在调用API时循环调用、智能体在完成多步任务时忘记最初指令、模型输出逐渐超出安全边界等。

最近笔记转换到了Obsidian,所以想开发了一个Obsidian插件

震求很简单,把Obsidian里面的笔记一键发布到公众号,在这个里面有个小的需求,需要把mermaid图转换成图片自动上传微信

类似hexo中的hexo-filter-mermaid-diagrams插件

hexo-filter-mermaid-diagrams 是一个用于 Hexo 的 Mermaid 插件。

它的核心思路不是“在构建时把 Mermaid 转成最终图片”,而是:

在页面中注入 Mermaid 脚本,等博客页面加载后,由浏览器再去渲染 Mermaid 图表。

但公众号里面不能这处理

微信公众号复制场景有个关键限制:

  • 粘贴到公众号编辑器后,不能依赖额外脚本继续执行 Mermaid

比如一个流程图:

Mermaid 自定义样式渲染修复

问题:Mermaid 图表中使用 style 指令自定义节点颜色(如 style B fill:#e1f5fe)时,导出到 PNG 后节点显示为黑色背景,丢失自定义填充色。

根本原因

  • Mermaid 将自定义样式写入 SVG 元素的 inline style 属性
  • Canvg 在光栅化时无法正确处理 inline style 的 CSS 优先级
  • <style> 块中的默认主题规则(如 .node rect { fill: #ECECFF; })覆盖了自定义样式

解决方案

  1. 保留 <style> 块(默认节点依赖它提供填充色和边框)
  2. 提取 inline style 中的 SVG 属性(fill、stroke 等)
  3. 为包含自定义样式的元素添加唯一 CSS 类
  4. 将提取的属性以 !important 规则追加到 <style> 块末尾
  5. 同时设置 SVG presentation attributes 作为兜底

这样既保证默认节点的样式完整,又通过 CSS 优先级确保自定义样式正确渲染。

使用 Claude Opus 4.6 模型

使用gpt-5.3-codex 和 gpt-5.4 模型

这么一个需求,模型知错、认错的功夫杠杠的,但就是改不了错

模型切了好几个,token花费不少,可最终问题还是没有完美解决

Agent 架构的演化逐渐分化出了四条最主要的路径:“Single Agent → Multi-Agent  → Agent Skills → Agent Teams”

Agent架构为什么需要演化,就是因为我们在 基础大模型无法完美内化“领域知识”和高效复用“长期记忆” 的背景下,不断尝试“外挂”出这些能力的。

本质上就是大家对大模型如何更好的注入领域知识和记忆管理这两方面的需求,不断促进了Agent架构的演化。

Single Agent架构

Single Agent指的是“狭义的”基于ReAct的自主Agent概念,使用System Prompt驱动、串行调用工具的原生Agent运行模式

核心逻辑

既然大模型无法直接内化我们特定的领域知识,那我们就通过System Prompt的方式,将这些知识“无脑”地注入到大模型的上下文中,期望它能基于这些注入的信息生成符合预期的答案。

你只需要将领域知识整理好,配合清晰的指令写入系统级指令的System Prompt中,再使用基础模型原生的ReAct模式自主调用工具、记录上下文并解决问题。

对于生成简单的代码段、写文案、执行某类标准化输出等场景,这种串行调用的单Agent模式往往能跑出最流畅的体验,是验证想法、ROI最高的原型方案

优势

实现简单、开发快、运行效率高,适合快速验证和简单场景。

劣势

上下文窗口易爆炸:注入海量知识会导致“关键信息遗忘”(Lost in the Middle)问题

长上下文并不等于长记忆。当输入数据量达到一定阈值时,模型极易出现“Lost in the Middle”问题,也就是“注意力缺失”或者“关键信息遗忘”的现象,导致其无法精准定位到所需的领域知识,最终输出的结果偏离预期

解决方案

行业普遍采用的解决方案是引入 RAG(检索增强生成)

[[RAG是什么]]

RAG 可以看作是在Single Agent基础上的一次重要演进。它的核心逻辑是“先搜后答”:在将知识注入大模型之前,先利用搜索工具进行一轮召回(Recall),仅将与用户问题相关度最高的那部分片段提取出来,作为上下文提供给 Agent。

这在一定程度上巧妙规避了 Context Window 的长度限制,让 Agent 能够“按需获取”知识,而非“全量吞咽”。然而,RAG架构的效果存在一个致命的依赖链——“垃圾进,垃圾出”(Garbage In, Garbage Out)。Agent 的 最终表现高度依赖于前置搜索环节的准确率。如果检索阶段未能召回正确的知识片段,无论后端的大模型能力多强,都无法生成正确的答案

flowchart TD
    A["用户问题
(例如:ECS远程连接失败?)"] --> B["嵌入模型
(小模型)"] B --> C["将问题转化为
向量"] C --> D["向量数据库
(存储着海量领域知识)"] D --> E{"相似性检索"} E --> F["召回 Top-K 个
最相关的知识片段"] F --> G["提示词组装"] G --> H["将问题 + 召回片段
组合成最终提示词"] H --> I["大语言模型
(LLM)"] I --> J["生成最终答案"] style A stroke-width:2px style B fill:#e1f5fe,stroke:#01579b style I fill:#fff9c4,stroke:#fbc02d style J stroke-width:2px

Reference

《Agent/Skills/Teams 架构演进过程及技术选型之道》

“虚中法”“子平法”学习框架

这份文档是一位命理老师在讲解八字命理学的核心框架与学习方法,内容详实,情绪激昂,旨在为学生厘清思路、夯实基础。以下是详细的内容总结:

一、核心思想与总论

  1. 强调基础的重要性:反复告诫学生不要追求“秘诀”,命理学博大精深但没有秘密,真正的核心都在经典之中。学习的关键在于“打基础”,必须反复研读经典和上课视频。

  2. 命理学的两大体系:明确指出八字命理主要分为 “虚中法”“子平法”,二者视角不同,但需要结合使用。

    • 虚中法(禄命法):以 年柱 为太极点(核心),论 先天之命。核心是“禄、命、身”加上神煞。看的是一个人与生俱来、命中注定的福禄、根基、体质等。

    • 子平法:以 日柱(日元) 为太极点,论 后天之运。核心是 月令格局 加上神煞。看的是一个人出生后,在具体的人伦社会中如何获取财富、地位、婚姻、子女等。

  3. “主本同参”原则:这是核心方法论。必须将 年柱代表的先天命日柱代表的后天运 结合起来看,不可偏废。先天命是根基,后天运是发挥。后天所得若与先天年柱的禄马贵气等呼应,则福大贵大;若脱节,则福贵减小。

二、具体方法论详解

  1. 论六亲

    • 年柱定六亲:决定命里“有没有”、先天缘分厚薄(“命里有时终须有”)。

    • 日柱定六亲:决定后天在社会中“如何得到”、关系相处的具体状态。

    • 二者需协调参看。

  2. 论婚姻

    • 主要看 日支(夫妻宫)月支

    • 同时必须结合 命宫 来起“十二宫”,其中 命宫的对宫就是夫妻宫。论婚姻时,要确保日支/月支的夫妻宫与十二宫的夫妻宫 不可交战,并综合查看两宫的神煞。

  3. 其他重要概念与用法

    • 胎元、胎息、胎变:三者与胎元所在之年,构成 “先天八字”。此盘不看十神,主要看地支的刑、冲、破、害,以及字形(如平头、悬针)和纳音交战,用于判断先天体质、有无夭折风险等。

    • 命宫:主要用于起“十二宫”(即“花園十二宫”),如命宫、夫妻宫、财帛宫等,用于多维度分析人生事项。

    • 神煞体系:是两大体系共用的重要部分。包括:

      • 马前神煞、太岁十二神。

      • 常用吉凶神煞:如红鸾、天喜、文昌、游奕、暗金煞、白衣、破碎、呻吟等。神煞需结合具体宫位和五行生克使用。

    • 虚中法看流年:核心是 “逐限而行”。将人生划分为不同年限(如年柱管1-16岁),重点看所行大运或流年 那一柱的天干地支,与年柱的禄命身产生何种生克合化及刑冲破害,并结合神煞,来判断该时段的吉凶。

    • 子平法论格局:核心是 月令分金定格局(如正官格、七杀格等)。需辨别格局的真假、成败。无格或破格时,则看喜用神。老师指出,真成格者(真富贵)极少。

    • 身强身弱:明确指出,身强身弱首先看年柱(年干、年支、纳音),这是先天体质根基。日元强弱是后天表现。日元强,承载财官的能力才强。

三、学习路径与经典推荐

  1. 核心经典(打基础必读)

    • 《渊海子平》:子平法的核心框架。

    • 《五行精纪》:虚中法(禄命法)的核心框架。

    • 《三命通会》:集大成的综合性经典。

  2. 其他经典作为视角补充:如《神峰通考》(讲病药)、《穷通宝鉴》(讲调候)、《子平真诠》(讲格局)等,它们提供了特定视角,但非全面基础。

  3. 学习方法

    • 先建立清晰框架:在脑中牢固建立“虚中-年柱-先天”和“子平-日柱-后天”两大框架,以及神煞、刑冲等公共方法。

    • 带着框架去学习:有了扎实基础和框架后,再去广泛听取各家之言,才能有判断力,将他人观点纳入自己的体系,而非被误导。

    • 重视赋文:如《千里马》、《络绎赋》、《金玉赋》等,这些是古人将理论应用于实战的总结,基础扎实后才能看懂并运用。

  4. 对市面上乱象的批判

    • 强烈反对自称“独创”、“秘传”而不引经据典的理论,认为“凡是离开经典的,皆是无源之水”。

    • 指出很多民间传承或盲派技法,其根源也公开承认来自上述经典。

    • 提醒学生睁大眼睛,谨慎对待那些标新立异、脱离经典的教学。

四、总结与劝诫

  • 最后归纳:八字的核心框架就是 “虚中的禄命身+神煞”“子平的月令格局+神煞” 的结合。刑冲破害、十二长生、旺相休囚等是服务于这两个核心的分析工具。

  • 终极劝告:“命理学没有秘密。命理学的基础逻辑在经典,实务传承在民间。” 要求学生沉下心来,回归经典,打好基础,以此立身,不贬低他人,但要有独立判断。

Harrison Chase(LangChain 联合创始人兼 CEO)那篇《How Coding Agents Are Reshaping Engineering, Product and Design》中文翻译:


编程Agent如何重塑工程、产品与设计

软件公司的 EPD(工程、产品与设计) 的核心是创建优秀的软件。虽然这些角色是分开的,但最终目标是产出能够解决商业问题、用户可用的功能性软件。归根结底,这一切都是代码。认识到 EPD 的产出本质上就是代码非常重要,因为……编程Agent突然让写代码变得非常容易。那么,这将如何改变 EPD 的角色呢?

流程的改变

1. PRD(产品需求文档)已死
在 Claude 时代之前,PRD 是软件开发的核心。EPD 的流程通常是这样的:

  1. 有人(通常是产品经理)有了一个想法
  2. 产品经理写一份 PRD
  3. 设计师根据 PRD 制作原型图
  4. 工程师将原型图转化为代码

想法 → PRD → 原型图 → 代码

这并非硬性规定(在初创公司这些步骤是融合的,最好的构建者能同时做多项工作),但这是教科书式的开发方式。

之所以这样,是因为构建软件(和原型图)需要大量的时间和精力。因此,人们创造了专门的学科来处理这些工作。随着专业化程度提高,跨学科沟通的需求也随之产生。PRD 就是这一切的基础,它启动了整个流程。然后它像瀑布一样流向设计,设计师将漂亮的文字转化为漂亮的 UI 和流畅的 UX。最后工程师将其变为现实。

编程Agent改变了这一切。 编程Agent可以直接将一个想法转化为功能软件。当我说(以及其他人说)“PRD 已死”时,我们真正的意思是:这种从撰写 PRD 开始的传统软件构建方式已经终结了。

2. 瓶颈从“实施”转移到了“评审”
现在任何人都能写代码,这意味着任何人都能构建东西。但这并不意味着构建出来的东西架构良好、解决了正确的问题或者易于使用。工程、产品和设计应该成为这些领域的评审者和仲裁者

问题是,生成的代码并不总是“优秀”的。EPD 的角色变成了评审并确保它是“优秀的”。“优秀”可以指代几层含义:

  • 工程系统视角: 架构是否可扩展、高性能且稳健?
  • 产品视角: 这是否解决了用户的痛点?
  • 设计视角: 界面是否易于使用且直观?

由于创建初始版本代码的成本极低,我们看到产生了更多的原型。这些原型成为焦点,由产品、工程和设计进行评审。

想法 → 代码 → [产品反馈 / 工程反馈 / 设计反馈]

问题是——生成代码太容易了。以前,创建代码需要很长时间,所以作为评审者,你桌面上待审的项目数量有限。但现在——任何人都能写代码。这意味着正在进行的项目数量在增加。我们发现瓶颈(在所有三个职能中)在于评审——即拿走这些原型并确保它们是“好”的。

3. PRD 万岁
Claude 时代之前的软件构建方式(从 PRD 开始)已经过去。但描述产品需求的文档仍然是必不可少的。

假设有人有一个想法并快速构建了一个原型。如何将其投入生产?它需要经过 EPD 的其他成员评审。在这个过程中,书面文档总是有帮助的,而且往往是必要的。当其他人进行评审时,他们怎么知道代码的某一部分是偶然存在的还是有意为之的?这取决于意图。需要某种形式的意图沟通。

我认为传统的 PRD 流程(PRD → 原型图 → 代码)已经死了。但描述产品需求的文本还活着。这份相关文档应该是原型的必备伴侣,在移交评审之前必须存在。最标准的格式是文档,但也有一些关于共享创建此功能所用提示词(Prompts)的有趣想法。如果未来的 PRD 只是结构化的、版本化的提示词呢?

想法 → 文档 → 代码 → [产品反馈 / 工程反馈 / 设计反馈]

对角色的影响

1. 通才比以往任何时候都更有价值
我说的通才,是指对产品、工程和设计都有良好感知的人。这些人一直都很有价值且有影响力——但在编程Agent时代,他们更是如此。为什么?
沟通是一切中最难的部分。它会拖慢进度。 一个能同时做产品、设计和工程的人,会比一个三人的团队跑得更快,因为没有沟通开销。

以前,当实施是阻碍时,这个通才仍然需要与他人沟通才能完成工作。现在他们只需要与Agent沟通。这意味着他们仅凭自己就能产生比以往任何时候都大得多的影响力。

2. 编程Agent是刚需
随着编程Agent让实施变得廉价,使用它们成为了一种要求。能够采用编程Agent的人将能凭一己之力做更多的事:

  • 产品经理: 采用编程Agent可以直接通过构建原型来验证想法,而无需撰写规格说明书和等待。
  • 设计师: 采用编程Agent可以在代码中迭代,而不仅仅是在 Figma 中。
  • 工程师: 采用编程Agent可以将时间从实施转移到系统思考。

采用编程Agent是刚需,因为这并不难,如果你不这样做,你就会被使用它的人取代。

3. 好的产品经理很棒,糟糕的产品经理很可怕
好的产品思维比以往任何时候都更有价值——你可以构建有用的东西。糟糕的产品思维比以往任何时候都更浪费。如果有人有一个糟糕的产品想法,他们可以带着一个原型出现——但这个原型将是一个无用或构思拙劣的功能。这些原型现在需要更多的评审——来自工程、产品和设计。这消耗了时间和资源。而且,将这些原型投入生产的惯性更大(“它已经存在了!我们就合并它吧!”)。这有制造出更差或臃肿产品的风险。

(此处原文有图表:糟糕的 PM 使用 AI 产生负价值,优秀的 PM 使用 AI 产生高价值)

4. 系统思考是需要磨练的技能
在一个执行廉价的世界里,系统思考成为了差异化因素。你应该专注于擅长系统思考,并对你特定的领域有清晰的心智模型:

  • 工程: 对如何架构服务、API 和数据库有极佳的心智模型。
  • 产品: 对用户真正需要什么(而不是他们说想要什么)有极佳的心智模型。
  • 设计: 对为什么某些东西看起来和用起来感觉对劲有极佳的心智模型。

系统思考一直很重要——那么什么变了?实施成本大幅下降。 这意味着实施某件事比以往任何时候都容易——但这并不意味着它很棒。成为一个好的系统思考者可以让你确保你一开始就构建了正确的东西。它也让你在事后评审他人的工作。这两点都意味着成为好的系统思考者的重要性增加了。

5. 每个人都需要产品感
编程Agent仍然需要有人向它们发出提示。有人告诉它们做什么。如果你告诉它们构建错误的东西——你就是在为其他人制造更多需要评审的垃圾。知道告诉Agent构建什么(“产品感”)是必须的,否则你会成为组织的拖累。这在工程、设计和(显然的)产品中都是如此。

EPD 的很大一部分现在是评审原型。如果你有产品感,评审设计/工程会更容易。如果你没有产品感,你需要一份与原型并行的超级详细的产品文档。如果你有产品感,你只需要最小的规格说明书就能理解功能的意图,从而加速沟通、评审和交付。

6. 专业化的门槛变高了
你需要知道如何使用编程Agent。你需要产品感。所有角色都在融合。

角色之间一直存在重叠。设计和产品长期以来联系紧密——在苹果和 Airbnb 等公司,设计师充当产品经理。“设计工程师”作为一种角色在 Vercel 等公司越来越流行。

这并不意味着没有专业化的空间。一个只思考系统架构的资深工程师仍然很有价值。就像一个没有掌握“氛围编码”(vibe coding)但对客户问题和构建内容有超级清晰心智模型的 PM 一样。设计师也是如此,他们可以理解和模拟用户旅程和交互,即使仍在使用 Figma。

专业化的门槛更高了。你不仅要精通你的领域,还要在评审上极快,并且是令人难以置信的沟通者。而且在任何给定的公司里,可能都没有那么多这些角色。

7. 你不是构建者,就是评审者
我们在 EPD 中看到了两种不同类型的角色正在出现。

第一:构建者(Builders)。 这种原型具有良好的产品思维,能够使用编程Agent,并具备基础的设计直觉。在一定的限制范围内(测试套件、组件库),他们可以将小型功能从想法推向生产,并为大型功能制作功能原型。

第二:评审者(Reviewers)。 对于大型和复杂的功能,需要详细的 EPD 评审。这对评审者的要求很高——你必须是你领域的杰出系统思考者。你还必须以快节奏工作——有太多东西需要评审。

如果你现在是一名工程师——你应该要么努力在系统设计上变得出色并习惯评审架构,立志成为一名评审者……要么尝试增长你的产品/设计技能并成为一名构建者。

如果你在产品或设计领域——你必须要么对产品/设计有极佳的心智模型并主要进行评审……要么跳进编程Agent并提高你的编码能力。

(此处原文有图表:横轴为工程能力,纵轴为产品/设计思维)

  • 独角兽(Unicorns): 高工程能力 + 高产品/设计思维(构建者)
  • 开始有麻烦的人: 低工程能力 + 高产品/设计思维(产品/设计评审者)
  • 开始有麻烦的人: 高工程能力 + 低产品/设计思维(工程评审者)
  • 总是有麻烦的人: 低工程能力 + 低产品/设计思维

有趣的是,角色正在某种程度上瓦解,如上图所示。角色开始融合——工程师有更多时间,可以更多地思考产品和设计。产品和设计可以创建代码。

8. 每个人都认为他们的角色从编程Agent中获益最大——而且他们是对的
Twitter 上有一篇关于从编程Agent中获益最大的人类型的精彩帖子:

“一个对现有产品有直观把握的人,知道它的软肋在哪里,哪里表现出色,以及如何将其迭代得更加锐利。
这种人的罕见版本存在于文化和深度技术的交界处。一个真正双语的人。他们知道技术上什么是可能的,也知道哪些文化潮流是真实的,哪些是短暂的。这种组合区分了那些感觉不可避免的产品和那些感觉是拼凑起来的产品。”

这篇文章很好地概括了这个新世界,它一度半病毒式传播。它之所以走红,是因为每个读到它的人都认为这是在说他们或他们的角色。我看到产品经理在引用它,设计师、设计工程师、创始人……每个人都认为它适用于他们和他们的角色。

而且他们可能都对!我认为这个新世界最令人兴奋的事情是,背景变得不那么重要了。我真心相信这种原型人物可能来自产品、设计或工程。这并不意味着每个人都会成为这种人——这说起来容易做起来难。真正的独角兽非常少。

这是一个令人兴奋的构建时代 :)

Skills一开始是由Claude发布的一种**为跨平台可移植性的开放标准。**它是指一个包含指令、脚本和资源的有序文件夹,代理可以动态发现并加载这些 文件夹,从而更好地完成特定任务。

To activate skills, all you need to do is write a SKILL.md file with custom guidance for your agent.

一般来说,一个完整的Skill,包含以下文件:

为什么它能解决 Context 膨胀?

因为它采用了渐进式披露 (Progressive Disclosure) 的机制:

  1. Discovery (扫描):Agent 启动时,只读取 SKILL.md 里的 namedescription。内存占用极小,只为了“知道有什么”。
  2. Activation (激活):只有当你的任务匹配到某个简介时(比如“处理 PDF”),Agent 才会动态加载完整的 SKILL.md 正文到 Context 中。
  3. Execution (执行):根据指令,按需调用 scripts 里的代码或读取 references 里的文档。

Skills有三个核心特点,也是它火起来的原因。

可组合。多个Skills可以协同工作,AI自动判断需要哪些,形成可复用的能力链。

可移植。同一个skill,Claude Code、Codex、Cursor、OpenCode都能用,不用改一行代码。

高效。只加载需要的,不浪费token和上下文长度。把上下文留给当下任务,而不是反复解释规则。

Agent Skills最大的改变就在于渐进式披露,其本质依然是行业中大家都在不断优化的提示词工程和上下文工程,其对提示词做了标准化拆分,通过在本地创建相关文件并控制文件的读取,只在Agent需要时自主且自动加载内容

就单拿提示词来说,我们在调用MCP时总要描述很多的工具提示词,在没有执行前,工具描述先把 Context 占满了。

反观Skills,Agent 最初只加载多个 Skills 的元数据(每个 Skill 占用几百 token),当 Agent 认为需要使用某个具体的 Skill,就会读取这个 Skill.md 说明(几千 token)

Skill 里还可以无限嵌套下去,告诉 Agent,想要深入了解某个具体问题,还可以继续读取哪份文件。

官方文档:
https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview

一、学习路径与方法

  1. 打好根基,循序渐进

    • 首要任务:必须首先熟练掌握“四季歌”。这是八字分析的第一步,用于判断日主在不同季节的先天旺衰和基本喜忌,从而定出命局的富贵贫贱基调。

    • 不要贪多求快:老师反复强调,在根基不牢时,不要看太多杂乱的知识,否则思路会混乱,变成“浆糊”。应该专注于核心基础,精专才能学好。

    • 先背诵,后简化:对于“四季歌”这类核心口诀,必须下功夫背诵熟记,理解其原理。只有在完全熟练之后,才能尝试使用简化方法去应用。在不熟的情况下追求捷径,心里会没底,判断不灵。

  2. 学习步骤

    • 第一步:拿到一个八字,首先用“四季歌”判断其季节喜忌,这已经能看出命局一半的高低好坏。

    • 第二步:在根基扎实后,再结合“财官”等十神知识,进一步分析格局和细节。

    • 第三步:结合大运走势。命局喜火,大运走东南木火之地则吉;命局喜水,大运走西北金水之地则吉。好运能提升层次,坏运则压抑发展。

二、核心学习态度与心法

  1. 目的与心态

    • 深层目的:学习命理浅层是看五行生克,深层是窥见“因果”。学习的最终目的不应是陷入对命运的焦虑或执着,而是调整心态、认识自我

    • 改变自己:老师强调,命理学习者首先应该做到的是改变自己。改变自己很简单,就是“放好心态”——不要情绪化,不要名利化。当你心思清净(清气上升),运气自然会改善。如果自己都改变不了,就无法影响他人。

    • 避免学“郁闷”:如果学完后反而让自己郁闷了,那就学“坏”了。正确的学习应该让人“开悟”,看淡得失,无论有钱没钱都能心态平和。

  2. 对“命”与“运”的认知

    • 命里有时终须有:命局中固有的东西(如财官印)才是根本的、可能终身拥有的。

    • 运里有时一时有:大运带来的东西是阶段性的,运过则无,是“虚妄”。

    • 修为的作用:命里没有的东西,可以通过后天的修行和修为来改进。这指向了个人心态和行为的调整。

三、实用总结与简化技巧

  • 四季月核心:无论什么五行,生于辰月、丑月(三月、十二月),首要需来调候;生于未月、戌月(六月、九月),首要需来滋润。

  • 季节总原则:夏天生的八字普遍需要水调候;冬天生的八字普遍需要火温暖。这是快速判断的大方向。

总而言之,老师倡导的学习方法是:从背诵“四季歌”等核心口诀打下坚实基础开始,专注精研,避免杂学混乱。在学习过程中,要摆正心态,以认识自我、调整心性为目的,最终达到“清气上升”、豁达开悟的境界,而非被命运所困。