回测 on 田稼禾 | 安全研究员

量化策略 v3 上线：从回测到分级门槛的完整迭代记录

Sun, 27 Sep 2026 00:00:00 +0000

一句话结论 #

用三阶段回测（18 只池内股 × 2025-01~2026-09，baostock 前复权）把模拟盘的负期望体系（胜率 30%、每笔期望 -474 元）改造成了正期望体系：全期 +1384%、近 30 天切片胜率 88.2%、单笔期望 +4.62%。本文记录完整的迭代过程、数据依据和踩坑，2026-09-28 起进入实盘模拟观察期。

起点：一个负期望系统 #

主模拟盘 2026-07-08 ~ 09-22 的 63 笔真实成交：

指标	数值	含义
净值	0.860 (-14%)	稳定亏钱
胜率	30%	10 笔只赢 3 笔
盈亏比	1.13	赢的时候赚太少
每笔期望	-474 元	交易越多亏越多

数学上很简单：30% 胜率要保本，盈亏比得 ≥ 2.4，实际只有 1.13。这不是运气差，是结构性负期望，微调参数救不了，必须动结构。

第一阶段：找 bug + 三项核心修复 #

1. 符号 bug：抄底策略实际在追高 #

最有意思的发现。超跌反弹策略里 drop_5d 定义为"下跌为正"，但判断写的是：

if drop_5d < -0.08: # 实际要求"上涨 8%"才加分！

也就是说这个策略从来没抄过底，一直在追高。修复后信号方向才真正对齐"超跌反弹"。

2. 止损：固定比例 → 2×ATR14 #

原固定 -3% 止损小于个股日波动率（3~4%），纯被噪音打掉。改为 入场价 − 2×ATR14，兜底不宽于 -8%：

变体	胜率	单笔期望
B 修复符号 bug	53.2%	+0.84%
D B + ATR 止损	76.7%	+2.62%

单这一项，胜率 +23.5 个点。

3. 大盘过滤：接飞刀问题的第一版 #

沪深300 < MA20 定义为熊市，熊市禁新开仓。回测有效（股灾月 -94% → -2.7%），先上了。但这里埋了个伏笔，见第三阶段。

第二阶段：探索更好的出场方式 #

在 E 方案（MA20 过滤 + ATR 止损）基础上测了 4 个变体：

变体	交易数	胜率	单笔期望	累计
E 基准	113	77.0%	+2.78%	+314%
G 分批止盈 (3%/6%/跟踪)	138	45.7%	+0.35%	❌ +48%
H 移动止损 (高点-2ATR)	108	50.0%	+2.79%	+302%
I 低门槛 2 分	485	68.9%	+1.82%	✅ +881%
J 趋势回调	119	68.9%	+1.66%	+198%

两个反直觉发现：

网红打法没有用：移动止损（让利润奔跑）在 A 股超短周期期望持平但胜率掉 27 个点，心理体验还差。
分批止盈是收益杀手：小步落袋过早掐断利润，期望从 +2.78% 掉到 +0.35%。虽然它是主盘的既定纪律（不擅动），但数据摆在这里。

I 变体做了稳健性检验：18 只池内股全部正期望（0 只负期望，单票期望 +0.30%~+4.04%），排除了过拟合。

第三阶段：近 30 天切片测试抓出的真问题 #

用户问了一句关键的话：“用近一个月的测试过吗？”

之前没单独切过。切片结果（2026-08-25 ~ 09-26，23 个交易日 100% 空头市）：

版本	交易	胜率	近30天累计
旧 bug 策略	27	63.0%	+17.9%
一刀切禁仓版	0	—	0%（全程空仓）
熊市分级版	17	88.2%	+78.6%

逐月拆解一刀切禁仓过滤器：

✅ 救过场：2026-07 股灾月，无过滤 -94.3% vs 有过滤 -2.7%
❌ 错过更多：2025-04(-50%)、2025-11(-83%)、2026-08(-50%)、2026-09(-53%) — 指数阴跌时高质量超跌反弹照样赚钱
全期总账：一刀切 +932% 居然跑输无过滤的 +1153%

解法：分级门槛 #

熊市不一刀切禁仓，而是提高信号门槛：牛市 ≥2 分开仓，熊市 ≥3 分（深跌+RSI超卖等更强确认）：

全期 20 个月	交易	胜率	累计
一刀切禁仓	451	70.7%	+932%
熊市 3 分级	613	73.1%	+1384%

股灾月 +106%（旧版 -2.7%）、近 30 天 +78.6%、全期 +1384%，三个维度全面胜出。

当前生效规则 #

信号评分: 3日跌5%(+2) 5日跌8%(+2) RSI7<30(+2)/<40(+1) 放量止跌(+2)
门槛: 牛市/中性 ≥2分 | 熊市(沪深300<MA20) ≥3分
止损: 入场价 − 2×ATR14 (兜底 -8%)
止盈: +6%
加仓: 金字塔, atr_width 锁定宽度随摊薄成本上移
周期: 1~10 天, 超时收盘离场

主盘保留熊市一刀切禁仓 + 分步止盈（仓位重、风控从严，刻意保留）。

实盘观察期与回滚条件 #

2026-09-28 起，每天 15:10 自动运行。回滚条件（任一触发）：

观察期真实胜率 < 50%
单笔亏损 > -8% 出现 3 次（ATR 止损失效信号）
熊市分级信号连续 5 笔全亏

必须泼的冷水 #

回测含理想成交假设：+6% 止盈默认精确成交，涨跌停/流动性会打折
近 30 天 +78.6% 来自 V 型反弹市，单边阴跌月（历史最差 -67%）仍可能出现
模拟盘才是终极裁判，4 周后用真实账本数据再回答"到底行不行"

复现脚本：backtest/run_backtest.py（阶段1）/ run_backtest_phase2.py（阶段2）/ run_bear_tier.py（阶段3）/ run_recent_check.py（近30天切片）。内部完整记录见 docs/策略迭代/策略迭代记录_v3_分级门槛上线_20260927.md。

两轮网站打磨记：从 AI 助手悬浮入口到全文 RSS

Sat, 26 Sep 2026 20:00:00 +0800

距离上一篇全站优化记快两个月了。这期间网站没大动，但积攒了两轮「体检 → 修复」的迭代：一轮偏 UI 与内容，一轮偏 基础设施与 SEO。还是老规矩，写下来给自己备忘，也给同样在折腾 Hugo 博客的朋友一个参考。

这次的改进方式：先体检，再动手 #

和上次「凭感觉改」不同，这两轮都是先做全站体检，把发现的问题按影响排序，确认了再改。体检维度包括：

移动端导航在不同宽度下的表现
分享卡片（og: tags）在微信/Twitter 里的实际观感
响应头（CSP、HSTS、缓存策略）、内链健康度
RSS 输出质量、结构化数据、图片加载优先级

好处很明显：避免为不存在的问题写代码。这次体检我还发现了两个自己误报的项——tutoring 页案例卡和 mermaid 按需加载其实都工作正常，是我 grep 模式太窄导致的假阴性。先验证再动手，省下了两次无意义的改动。

第一轮：UI 与内容 #

移动端导航：basic → hybrid #

这是两轮里影响最实际的一项。Congo 主题的 header 之前用的是 basic 布局，桌面端横排没问题，但手机上 10 个导航链接会竖排挤满首屏，用户要滑很久才能看到正文。

改法就一行配置：

[header]
 layout = "hybrid" # 手机汉堡菜单, 桌面保持横排

hybrid 是主题现成的第三种布局：窄屏收进汉堡按钮，宽屏照旧横排。改完用浏览器实测了菜单展开、桌面布局不变、无控制台报错。主题作者早就把路铺好了，我们只是没翻到那一页配置。

分享卡片标题统一 #

浏览器标签页显示「田稼禾 | 安全研究员」，但微信/Twitter 分享出去的卡片标题却是「田稼禾的个人网站」——两个 title 来源不同步（hugo.yaml 和语言配置各管一个）。统一成同一个值，分享出去的第一印象才一致。

内容扩充：实习经历从 6 条到 11 条 #

把 obsidian 里两段实习的 70+ 篇笔记重新翻了一遍，安全研究页的实习经历做了内容扩充，每条都有真实笔记出处：

安全运营方向：零信任办公自动化、告警降噪规则治理、密钥治理、CI/CD 部署链路、SOAR 剧本开发
AI 安全研究方向：CVE 跟踪、指纹规则逆向、漏洞复现与 PoC 编写、AI Agent 安全框架调研

后来又按隐私考虑把实习板块做了匿名化——公开页面不出现具体单位名称和内部系统组合，细节留在简历和面试里讲。

体会是：简历素材不在记忆里，在笔记里。当时觉得琐碎的记录，两个月后就是现成的 bullet。

全站 AI 助手悬浮入口 #

AI 简历助手原来只有首页有入口，其他页面要回首页才能找到。这次在右下角加了一个全站悬浮按钮：

复用主题渐变配色 + 呼吸光环动画（@keyframes + prefers-reduced-motion 降级）
点击跳转 /ai/，落地自动弹出对话窗——零新增 JS，复用页面已有的自动弹窗逻辑
/ai/ 页自身通过 Hugo 模板条件判断隐藏按钮（那里已有完整入口），打印时也不显示

实现思路：全站注入点用 extend-footer.html partial，样式进 custom.css。悬浮按钮这种小功能，最容易犯的错是为此引入一坨 JS——其实 Hugo 的模板条件 + CSS 动画就够了。

第二轮：基础设施与 SEO #

RSS 从摘要升级为全文 #

Hugo 内置的 RSS 模板输出的是 .Summary，订阅者只能看到 218 字摘要。覆盖 layouts/_default/rss.xml 后：

每篇文章输出全文 content:encoded（实测 20 篇全部 7千~3万字）
每条 item 带 enclosure 配图
只输出真正的文章页——原版会把「随笔」「系列目录」这类列表页也混进去，是噪音

改的过程踩了个坑：第一版模板在无子页面的路由上 $pages 为空，first 函数直接报错。兜底逻辑要显式处理边界。

头像 LCP 优先级修正 #

首页头像是首屏最大的图片元素（LCP），之前却标着 loading="lazy" + fetchpriority="low"——等于告诉浏览器「这个最不着急」。对 LCP 元素这是反向优化。改法：

<!-- 前: loading="lazy" fetchpriority="low" -->
<!-- 后: fetchpriority="high"（去掉 lazy） -->

一行属性，移动端首屏出图更快。lazy loading 不是万能优化，首屏元素用它就是负优化。

内容归类修补 #

《网站安全加固全记录》原来只归「网站建设」，导致 /research/（AI 安全研究专题）收不到它。补上双分类 ["网站建设", "安全研究"]，专题页从 18 篇到 19 篇。双重身份的内容就该有两个入口。

体检中确认健康的部分 #

也有不少维度查过之后确认没问题，记下来避免以后重复怀疑：

安全响应头全套在线（CSP / HSTS / X-Frame-Options / Permissions-Policy）
静态资源 immutable 一年缓存 + gzip（60KB CSS 传输只 11KB）
robots / sitemap / JSON-LD / favicon 全套齐
AI 后端被 systemd 正规托管（enabled + Restart=on-failure + MemoryMax）
内链抽查无死链，四个专题页内容都在

几点新体会 #

1. 先验证「问题是否存在」，再动手修 #

这轮最大的收获。两次「发现的问题」其实是我检测方式的问题，不是网站的问题。花 30 秒换个姿势验证，比写半小时无用代码划算。

2. 主题的覆盖点比想象中多 #

layout = "hybrid"、extend-footer.html、rss.xml 覆盖——这次用到的三个改动全部是 Hugo 的模板覆盖机制，一行主题代码都没改。升级依然无冲突。

3. 体检要换维度做 #

上轮查了 UI 和内容，这轮查响应头、RSS、结构化数据、进程托管——不重复的维度才有新发现。下次再体检，可以看看 Core Web Vitals 实测数据和 Lighthouse 跑分。

系列前篇：个人博客全站优化记。这个系列还在继续，网站和我一样，都是边跑边修。

ETF 龙头关注策略：跨市场配置的量化实现

Fri, 28 Aug 2026 00:00:00 +0000

一句话结论 #

个股策略盯的是超跌反弹的择时机会，而 ETF 策略解决的是另一件事——用一篮子真实龙头降低个股地雷风险，实现跨市场、跨风格配置。两者完全独立：独立建池、独立信号、独立推送。

flowchart TD
 A[量化系统] --> B[📈 个股策略]
 A --> C[📦 ETF策略]
 B --> B1[stock_pool.py: 17只]
 B --> B2[超跌反弹+趋势择时]
 B --> B3[cron 09:30 推送]
 C --> C1[etf_pool.py: 9只]
 C --> C2[跨市场板块信号]
 C --> C3[cron 09:35 推送]

一、为什么专门做 ETF，而不是都买个股 #

把盈利将这句话作为前提：“发现龙头，拥抱龙头，陪伴龙头”。但拥抱龙头有个现实难题——单一个股的龙头地位可能被技术迭代颠覆，也可能因为估值、情绪被错杀。

ETF 用一个结构化解掉这个难题：把行业里公认的龙头打包成一只基金，跟踪指数、分散持仓。这样：

享受行业的龙头红利，又规避押注单一公司的风险
无需深入研究每一家公司的财报，行业景气度就够
流动性好，买卖成本低（场内 ETF 免印花税）

而且 ETF 天然适配你的跨市场配置需求：A股半导体、海外科技、红利防御，一个池子全装下。

二、ETF 池结构（`etf_pool.py`） #

代码锚点：/home/ubuntu/quant_repo/etf_pool.py

ETFS = {
 # 科技/半导体（进攻主线）
 "512480": "半导体ETF", # 国内半导体产业链龙头打包
 "588000": "科创50ETF", # 科创板50大龙头（中芯/海光/中微）
 "515000": "科技ETF",
 "159995": "芯片ETF",

 # 宽基（防御/均衡）
 "510300": "沪深300ETF",

 # 海外/美股（全球化配置）
 "513100": "纳指ETF", # 纳斯达克100，美股科技龙头
 "513500": "标普500ETF", # 标普500，美股大盘

 # 医药 / 红利
 "512010": "医药ETF",
 "510880": "红利ETF", # 上证红利，高股息价值
}

GROUPS = {
 "半导体/AI": ["512480", "588000", "515000", "159995"],
 "宽基/防御": ["510300"],
 "海外/美股": ["513100", "513500"],
 "医药/健康": ["512010"],
 "红利/价值": ["510880"],
}

设计取舍 #

为什么分组：日报按板块展示，一眼看出哪条主线在动，避免 9 只 ETF 堆成一坨分不清。
为什么只选代表：每个板块只放最强那只，不搞重复。纳指你只要一个 513100，标普你只要 513500，再加别的同类就是信息冗余。
池子独立文件：和股票池 stock_pool.py 彻底分开，增删互不影响，单独维护。

三、数据层的坑：ETF 代码识别 + 反爬 #

这是整个策略最容易翻车的地方。ETF 代码以 5（沪）和 1（深）开头，而普通股票是 6/0/3。如果数据源不识别这些前缀，ETF 会全部抓不到数据。

修复：识别交易所前缀 #

代码锚点：/home/ubuntu/quant_repo/data/fetcher.py

# akshare 需要带交易所前缀
if symbol.startswith(("6", "5", "688", "9")): # 沪市股票 + ETF + 科创板
 ak_symbol = f"sh{symbol}"
elif symbol.startswith(("0", "3", "1")): # 深市股票 + ETF
 ak_symbol = f"sz{symbol}"

反爬：akshare 拿不到，走 baostock 兜底 #

实测发现：akshare 的东方财富接口对 ETF 有反爬，会返回 RemoteDisconnected 断连或解析失败。但 baostock 完全支持 ETF，数据完整。

依赖现有的多源自动 fallback机制，上层接口不变，一个源挂了自动切下一个：

[akshare] 获取 512480 失败 → 自动切 [baostock] 成功 (41行)
[akshare] 获取 513100 失败 → 自动切 [baostock] 成功 (42行)

这验证了那句架构原则：多源 fallback 比单源加缓存可靠。真正的兜底是"还有别的源能用"，而不是"重试同一个坏源"。

四、信号计算（`etf_monitor.py`） #

与个股共用 RSI 超跌逻辑，但独立实现，参数可单独调：

def calc_etf_signal(code, fetcher, today):
 df = fetcher.get_stock_daily(code, start, end)
 close = df["close"].values
 chg5d = (close[-5] - close[-1]) / close[-5] # 5日跌幅
 rsi = compute_rsi(close[-14:]) # 14日RSI

 score = 0
 if chg5d > 0.03: score += 1; reasons.append(f"5日跌{chg5d:.1%}")
 if rsi < 30: score += 2; reasons.append(f"RSI({rsi:.0f})深度超卖")
 elif rsi < 38: score += 1; reasons.append(f"RSI({rsi:.0f})偏低")
 if chg1d > 0 and rsi < 40: score += 1; reasons.append("企稳")

 return {"signal": "buy" if score >= 3 else "hold", ...}

设计取舍 #

ETF 信号阈值比个股宽松（score≥3 vs 个股≥4）：因为 ETF 波动小、不需要太苛刻的深度超跌，回调稍深就是配置机会。
宽基/防御 ETF 不追高：日报末尾会提示"宽基做配置用，不追高"，红利这类慢牛标的要控制预期。

五、与个股独立配置 + 独立推送 #

独立 cron #

个股日报和 ETF 日报是两个完全独立的任务：

股票日报 scheduled_daily.py -> cron 09:30
ETF日报 etf_monitor.py -> cron 09:35（工作日）

为什么要 09:35 而不是挤在 09:30？因为微信 iLink 有 30 秒冷却，两条消息同时发会互相触发限流、导致一条被吞。错开 5 分钟，既独立又稳定。

增删方式（你说了算） #

和股票池一样，ETF 池也每天在日报里列出，你拍板增减：

「加 XX ETF」→ 改 etf_pool.py 的 ETFS + GROUPS
「删 XX ETF」→ 移除对应行
下次 09:35 日报自动反映

六、这套池子现在长什么样 #

2026-08-28 实跑输出：

▫️ 半导体/AI
 ◽ 半导体ETF(512480) 现价1.063 日+4.5% RSI47 无信号
 ◽ 科创50ETF(588000) 现价1.788 日+3.9% RSI37 偏低|企稳
▫️ 宽基/防御
 ◽ 沪深300ETF(510300) 现价4.691 日+0.8% RSI54 无信号
▫️ 海外/美股
 ◽ 纳指ETF(513100) 现价2.229 日+1.2% RSI37 偏低|企稳
 ◽ 标普500ETF(513500) 现价2.708 日+0.0% RSI47 无信号
▫️ 医药/健康
 ◽ 医药ETF(512010) 现价0.386 日+0.5% RSI38 企稳
▫️ 红利/价值
 ◽ 红利ETF(510880) 现价3.454 日+0.4% RSI55 无信号

9 只 ETF，覆盖进攻（半导体/AI）、平衡（宽基/海外）、防守（医药/红利）三条线，跨 A股+美股两个市场。

验证命令 #

# 更新池文件
cd /home/ubuntu/quant_repo && source .venv/bin/activate
python etf_pool.py

# 手动跑 ETF 日报（验证数据+信号）
python etf_monitor.py

# 单只 ETF 数据是否可拉
python -c "from data.fetcher import DataFetcher; f=DataFetcher(); df=f.get_stock_daily('513100','2026-07-01','2026-08-28'); print(df.tail(2))"

下一步 #

这套 ETF 池目前是监控模式——盯信号、给配置建议，但不自动交易。后续可以：

给 ETF 也建买入/止盈/止损的执行器，和个股一样跑模拟盘
增加 ETF 与个股的相关性分析，做真正的组合层面风控（避免看似分散实则同涨同跌）
评估是否纳入黄金/债券 ETF做避险压舱石

由 AI 基金经理自动管理，持续进化中。

个人博客全站优化记：从视觉风格到分类体系的完整升级

Fri, 31 Jul 2026 18:00:00 +0800

这两天对个人博客做了一次完整的全站优化，从首页视觉风格到分类体系，踩了一些坑，也想清楚了很多事情。记录下来，给自己做个备忘，也给同样用 Hugo 搭博客的朋友做个参考。

为什么要做这次优化 #

之前博客的状态其实是能用的，但总觉得少了点什么：

首页几个区块的交互风格不统一，有的是卡片有的是纯链接，视觉上有点乱
文章分类几乎没有，读者看完一篇找不到相关的内容
没有标签体系，内容沉淀不下来

这次的目标很简单：让首页风格彻底统一，搭好完整的内容分类架构。

关于设计的思考：少即是多 #

一开始我走了弯路，把首页做成了很重的卡片风格，每个链接都加边框、加阴影、加 hover 动效。结果看起来特别拥挤，失去了 Congo 主题原本那种清爽极简的感觉。

后来全部回滚，做了一个决定：全站只保留一种链接 hover 效果——纯文字变色。

<a class="group" href="...">
 <strong class="group-hover:text-primary-600 dark:group-hover:text-primary-400">标题</strong>
 <span class="text-neutral-600 dark:text-neutral-400">描述</span>
</a>

没有背景、没有边框、没有阴影、没有位移，就这么简单。

效果反而出奇的好。整个页面干净了很多，阅读时注意力不会被多余的动效分散。

设计最重要的不是加什么，而是敢于删什么。

三层分类体系搭建 #

这是这次优化最核心的部分。用 Hugo 原生的 Taxonomy 系统，搭了三层分类：

层级	名称	粒度	示例
L1	categories（分类）	粗	技术研究 / 量化研究 / 随笔
L2	tags（标签）	细	Hugo / 安全 / Agent / 量化
L3	series（系列）	系列化	SecurityClaw 学习系列 / 博客优化系列

为什么要分三层？因为人的浏览习惯是不一样的：

有人喜欢按分类逛：想看看你都做过哪些方向的研究
有人喜欢按标签找：就想看所有跟"安全"相关的文章
有人喜欢追系列：想把 SecurityClaw 整个系列按顺序看完

三层覆盖了所有浏览场景。

标签云页面 #

标签云不是随便列出来就完事了，做了一个很重要的细节：标签字体大小随文章数量动态变化。

{{ $count := .Count }}
{{ $size := add 0.8 (mul (div (float $count) 10) 0.8) }}
{{ if gt $size 2.0 }}{{ $size = 2.0 }}{{ end }}

这样写得多的标签自然会更大更醒目，读者一眼就能看到你主要在写什么，相当于自动生成的"技术画像"。

这次调整的文件清单 #

做了这些改动，都是无侵入式的：

config/_default/hugo.toml # 新增三层 taxonomy 配置
config/_default/menus.zh-CN.toml # 导航栏加标签云和分类
layouts/_default/terms.html # 标签云/分类列表模板
layouts/_default/term.html # 单个标签/分类的文章列表页面

核心原则：尽量不修改主题原有文件，全部用 Hugo 的模板覆盖机制来做。以后 Congo 主题升级时不会冲突。

几个重要的原则总结 #

这次折腾下来，有几个感受特别深：

1. 最小改动原则 #

不要一上来就大改主题的核心文件。先想清楚是不是真的需要改，能不能用更轻的方式实现。

一开始我想改 Congo 的 list.html 来显示标签，后来发现主题本身就内置了 list.showTaxonomies 配置。一行配置就能解决的事，差点写了一百行模板。

2. 视觉一致性比"好看"更重要 #

一个到处都是不同 hover 效果的"好看"页面，远不如所有交互完全统一的普通页面体验好。

用户不需要学习三种不同的点击反馈，一种就够了。

3. 分类体系要提前搭 #

博客刚起步时文章少，分类的价值看不出来。等到写了几十上百篇，内容就会开始乱。

提前把三层分类搭好，写文章时顺手加几个标签，积累半年回头看就是一笔巨大的财富。

接下来的计划 #

这个博客的优化还没完，接下来想做的几件事：

文章底部加相关文章推荐，基于标签匹配
系列文章的前后导航（上一篇 / 下一篇）
更清晰的专题落地页
全站搜索

博客是个慢工程，不用追求一次做完美。先把骨架搭好，慢慢迭代。

写技术博客这件事本身，就是最好的持续学习。

个人博客全站优化记：从视觉风格到分类体系的完整升级

Fri, 31 Jul 2026 18:00:00 +0800

为什么要做这次优化 #

之前博客的状态其实是能用的，但总觉得少了点什么：

首页几个区块的交互风格不统一，有的是卡片有的是纯链接，视觉上有点乱
文章分类几乎没有，读者看完一篇找不到相关的内容
没有标签体系，内容沉淀不下来

这次的目标很简单：让首页风格彻底统一，搭好完整的内容分类架构。

关于设计的思考：少即是多 #

后来全部回滚，做了一个决定：全站只保留一种链接 hover 效果——纯文字变色。

<a class="group" href="...">
 <strong class="group-hover:text-primary-600 dark:group-hover:text-primary-400">标题</strong>
 <span class="text-neutral-600 dark:text-neutral-400">描述</span>
</a>

没有背景、没有边框、没有阴影、没有位移，就这么简单。

效果反而出奇的好。整个页面干净了很多，阅读时注意力不会被多余的动效分散。

设计最重要的不是加什么，而是敢于删什么。

三层分类体系搭建 #

这是这次优化最核心的部分。用 Hugo 原生的 Taxonomy 系统，搭了三层分类：

层级	名称	粒度	示例
L1	categories（分类）	粗	技术研究 / 量化研究 / 随笔
L2	tags（标签）	细	Hugo / 安全 / Agent / 量化
L3	series（系列）	系列化	SecurityClaw 学习系列 / 博客优化系列

为什么要分三层？因为人的浏览习惯是不一样的：

有人喜欢按分类逛：想看看你都做过哪些方向的研究
有人喜欢按标签找：就想看所有跟"安全"相关的文章
有人喜欢追系列：想把 SecurityClaw 整个系列按顺序看完

三层覆盖了所有浏览场景。

标签云页面 #

标签云不是随便列出来就完事了，做了一个很重要的细节：标签字体大小随文章数量动态变化。

{{ $count := .Count }}
{{ $size := add 0.8 (mul (div (float $count) 10) 0.8) }}
{{ if gt $size 2.0 }}{{ $size = 2.0 }}{{ end }}

这样写得多的标签自然会更大更醒目，读者一眼就能看到你主要在写什么，相当于自动生成的"技术画像"。

这次调整的文件清单 #

做了这些改动，都是无侵入式的：

config/_default/hugo.toml # 新增三层 taxonomy 配置
config/_default/menus.zh-CN.toml # 导航栏加标签云和分类
layouts/_default/terms.html # 标签云/分类列表模板
layouts/_default/term.html # 单个标签/分类的文章列表页面

核心原则：尽量不修改主题原有文件，全部用 Hugo 的模板覆盖机制来做。以后 Congo 主题升级时不会冲突。

几个重要的原则总结 #

这次折腾下来，有几个感受特别深：

1. 最小改动原则 #

不要一上来就大改主题的核心文件。先想清楚是不是真的需要改，能不能用更轻的方式实现。

一开始我想改 Congo 的 list.html 来显示标签，后来发现主题本身就内置了 list.showTaxonomies 配置。一行配置就能解决的事，差点写了一百行模板。

2. 视觉一致性比"好看"更重要 #

一个到处都是不同 hover 效果的"好看"页面，远不如所有交互完全统一的普通页面体验好。

用户不需要学习三种不同的点击反馈，一种就够了。

3. 分类体系要提前搭 #

博客刚起步时文章少，分类的价值看不出来。等到写了几十上百篇，内容就会开始乱。

提前把三层分类搭好，写文章时顺手加几个标签，积累半年回头看就是一笔巨大的财富。

接下来的计划 #

这个博客的优化还没完，接下来想做的几件事：

文章底部加相关文章推荐，基于标签匹配
系列文章的前后导航（上一篇 / 下一篇）
更清晰的专题落地页
全站搜索

博客是个慢工程，不用追求一次做完美。先把骨架搭好，慢慢迭代。

写技术博客这件事本身，就是最好的持续学习。

我的个人网站安全加固与优化全记录

Tue, 28 Jul 2026 00:00:00 +0000

背景 #

前几天把博客从 Congo v1 升级到了 v2，页面是好看了，但也埋下了不少坑。正好想试试 Claude Code 的「在线网站分析」能力，于是就有了这次完整的整改闭环：

Claude Code 爬取线上网站 → 生成问题清单 + 整改建议 → 逐项修复验证

整个过程非常丝滑，从发现问题到全部上线，花了不到 2 小时。

第一轮：发现问题 #

用 Claude Code 打开我的博客首页，不到 1 分钟就输出了一份非常精准的问题清单，甚至带上了修复优先级。

🚨 High Priority #

首页 meta description 为空
- Hugo 模板逻辑有问题，首页 front matter 的 description 没被正确读取
- 影响 SEO，搜索引擎抓取不到正确描述
家教页推荐徽章位置错误
- 「推荐」徽章在高中 ¥120 卡片上，而不是高三 ¥150
价格卡片 CSS 渲染错乱
- 课程设计模块颜色、排版都有问题

⚠️ Medium Priority #

About 页图片占位位置错误
- 顺序是「标题 → 图片占位 → 介绍语」，应该是「标题 → 介绍语 → 图片占位」
首页「现在在做」卡片不可点击
- 三个卡片分别应该跳转到安全研究、SecurityClaw 专题、量化页面
缺少自定义 404 页面
- 访问不存在的路径时返回默认 404，体验很差

🔍 优化建议 #

博客单篇文章加右侧浮动 TOC
- 长文没有目录，阅读体验不好
补充安全响应头
- HSTS / CSP / Permissions-Policy / 隐藏 Server 头
检查 sitemap 空条目
- Hugo 生成的 sitemap 可能包含空 <url> 标签

第二轮：逐项修复 #

1. meta description 修复 #

问题定位：Congo 模板的 head.html 里 description 绑定逻辑有多层 fallback，但首页 content/_index.md 的 front matter 虽然写了 description，但实际渲染出来是空的。

解决：直接在 languages.zh-CN.toml 里加全局 params.description 作为最终兜底。

[params]
 description = "网络空间安全学生，专注 Web 安全、代码审计、AI Agent 安全研究，持续更新技术博客。"

2. 家教页完全重构 #

原页面用的是 Markdown 内嵌 HTML 写法，导致 CSS 类经常被转义或错乱。

改成纯 Hugo 布局模板 layouts/_default/tutoring.html：

价格卡片用 Tailwind 的 group + hover 状态
高三卡片加琥珀色边框 + 右上角推荐徽章
教学理念三卡片独立区块
真实案例区块结构化
联系方式与二维码占位

还顺手把所有 bg-white/50 这种带透明度的背景改成了实色，暗色模式下不再有发白割裂感。

3. 首页卡片可点击 + hover 上浮 #

原来三个卡片只是静态文本，用户想点却点不了。

<a href="{{ "/securityclaw-learning/" | relURL }}" 
 class="p-4 rounded-lg bg-neutral-100 dark:bg-neutral-800/50 
 hover:ring-2 hover:ring-primary-400/30 
 hover:-translate-y-0.5 transition-all cursor-pointer">
 <!-- 卡片内容 -->
</a>

加了 hover:-translate-y-0.5 轻微上浮效果，交互感立刻就有了。

4. 自定义 404 页面 #

layouts/404.html：

{{ define "main" }}
<section class="mx-auto max-w-2xl py-20 text-center">
 <h1 class="text-6xl font-bold text-primary-500">404</h1>
 <p class="mt-6 text-xl">🛡️ 请求的资源不存在，或已被安全策略拦截。</p>
 <p class="mt-3 text-neutral-500">Attack pattern detected? 别慌，只是页面走丢了。</p>
 <a href="/" class="mt-8 inline-block px-6 py-3 rounded-lg bg-primary-500 text-white hover:bg-primary-600">返回首页</a>
</section>
{{ end }}

Caddy 配置配合：

handle_errors {
 @404 expression {http.error.status_code} == 404
 rewrite @404 /404.html
 file_server
}

5. 安全响应头加固 #

直接在 Caddyfile 里加完整 header 块：

header {
 # HSTS 一年
 Strict-Transport-Security "max-age=31536000; includeSubDomains"
 
 # CSP - 静态博客够用的宽松策略
 Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self'; frame-ancestors 'none'; base-uri 'self'; form-action 'self'"
 
 # 禁用不需要的浏览器 API
 Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=()"
 
 X-Content-Type-Options nosniff
 X-Frame-Options DENY
 Referrer-Policy strict-origin-when-cross-origin
 
 # 隐藏 Caddy 版本
 -Server
}

第三轮：验证与验收 #

✅ 功能验证清单 #

检查项	结果
meta description	正确渲染
推荐徽章在高三卡片	✅
价格卡片 hover 效果	✅
首页卡片可点击跳转	✅
404 页面正常返回 404	✅
CSP 不影响 Mermaid 渲染	✅
CSP 不影响 fuse.js 搜索	✅
CSP 不影响主题切换	✅
Sitemap 空条目	0 个
Server 头隐藏	✅

📝 最终修改文件 #

/etc/caddy/Caddyfile # 安全响应头 + handle_errors
layouts/_default/tutoring.html # 家教页纯模板重构
layouts/_default/404.html # 自定义 404
layouts/partials/home/custom.html # 卡片 hover 上浮
content/_index.md # description 修正

感想 #

这次体验让我对 AI + 本地开发代理 的工作流有了更深的感受：

Claude Code 当自动化测试：它能像真实用户一样浏览网站，发现各种视觉 bug 和功能缺陷，比我自己一页页翻高效太多
Hermes 当执行代理：拿到整改清单后，改 Caddyfile、改 Hugo 模板、构建部署、curl 验证，全程不用我动手
验证闭环很重要：每改完一项立刻用 curl 验证，避免「以为修好了实际上没生效」的尴尬

整个过程就像有个自动化测试团队 + 运维团队，我只需要看报告就行。这种开发体验真的会上瘾。

🌐 最终成果：https://tttjhgan.top

持续学习工作流 2.0：6 个 AI 工具的分工、边界与知识汇流

Mon, 27 Jul 2026 00:00:00 +0000

先说结论 #

我现在越来越确认一件事：学习效率高不高，不取决于你装了多少 AI 工具，而取决于你有没有一个稳定的知识流。

工具可以很多，但信息最好只有一条主线。

如果今天用桌面版 GPT 想东西，明天在浏览器里用 Sider 看网页，后天在云主机上让 Agent 跑任务，再加上本地开发、知识库、零碎笔记、思维导图全都散着放，短期会很爽，长期就很容易出现一个问题：

你看了很多，做了很多，但最后沉淀下来的东西很少。

所以这篇文章不是单纯列工具，而是把我现在这套学习/工作流拆开，看看每个工具该放在哪个位置，它们之间怎么配合，以及如何避免工具之间互相内耗。

一、什么叫工具互相内耗 #

AI 工具多了以后，真正的问题通常不是“不够强”，而是都能干一点，于是谁都在抢活，最后谁都没把事情做完整。

你会很容易遇到这种场景：

想总结一个概念，桌面 GPT 能做
正在看网页，Sider 也能做
想自动整理一下，Agent 似乎也能做
顺手想写笔记，Obsidian 里也能记
想边做边试，Trae 还能直接生成原型

看起来每个工具都很能打，但真正的问题是：

如果没有分工，这些工具不会叠加效率，只会叠加切换成本。

我理解的内耗，不是工具卡顿，而是下面这些情况：

同一个问题被你在 3 个 AI 里重复问一遍
同一种总结被你写在 2 个地方，最后哪个是最新版都不清楚
某个任务本来该交给 Agent 持续跑，你却反复手动做
某个想法本来只是临时实验，却被你当成正式沉淀
某个工具本来只是辅助理解，你却把它当长期知识库

这些情况最大的坏处不是浪费几分钟，而是让你的认知链条断掉。

flowchart LR
 A[同一个问题多处重复处理] --> B[上下文被切碎]
 B --> C[版本混乱]
 C --> D[沉淀变少]
 D --> E[越学越忙 但收获不成体系]

所以“防内耗”的本质，不是限制工具，而是建立边界。

二、分工的原则，不是按品牌分，而是按任务分 #

很多人分工具是这么分的：

这个是 OpenAI 的
这个是浏览器插件
这个是本地 IDE
这个是云端 Agent

这种分法不够用。真正有用的分法应该是：

谁负责即时思考
谁负责长期执行
谁负责网页上下文
谁负责实验
谁负责沉淀

也就是说，工具应该按任务类型分层，而不是按产品名字分层。

三、6 个工具的明确分工方案 #

1. 桌面版 GPT：负责“即时思考” #

桌面 GPT 最适合干的事，是高频、短反馈、需要连续对话的任务。

比如：

拆概念
问为什么
帮你理一个思路
草拟提纲
对比两个方案
快速复盘一件事

它不适合做什么？

长期自动执行
多步骤持续运行任务
需要稳定文件环境的流程
当最终知识库

一句话概括：

桌面 GPT 是你的思考界面，不是你的后台系统，也不是你的档案馆。

2. Hermes Agent（云主机）：负责“持续执行” #

云主机上的 Hermes Agent 更像一个后台大脑。它适合干那些要跑、要连、要持续的任务。

比如：

自动化脚本
cron 定时任务
博客发布
模拟盘报告
笔记加工
多步文件处理
工作流串联

它不该替代什么？

日常所有零碎提问
纯粹为了想一想的闲聊
明明一句话能解决却非要上完整流程的任务

一句话概括：

Hermes Agent 是执行系统，不是随手聊天窗口。

3. Sider：负责“网页就地辅助” #

Sider 这种浏览器侧 AI，本质上解决的是一个很具体的问题：

你正在看网页，但你不想复制来复制去。

它适合的场景包括：

摘要长文
翻译英文页面
解释网页里的陌生词
快速比较多段网页内容

但它不适合：

做最终沉淀
代替系统学习
代替知识库管理

一句话概括：

Sider 是输入辅助器，不是沉淀中心。

4. Trae / vibe coding：负责“实验和原型” #

Trae 这类环境最适合的是探索阶段，因为快。

它负责：

快速搭 demo
测试一个小想法
写最小可运行原型
验证某个方案值不值得继续投入

但它有一个明显风险：很容易产出很多临时结果，却没有被系统整理。

所以它该承担的角色是：

实验层，不是归档层。

实验可以在本地快速长出来，但实验结论不能只留在聊天记录里，最后还是要回 Obsidian。

5. 腾讯 ima：负责“轻收集和补充仓” #

腾讯 ima 这种产品，如果你觉得“貌似还不错”，那它比较适合放在一个中间层。

也就是说：

临时资料收集
某个专题的快速归档
面向移动端或轻输入场景的知识堆叠
作为外部知识容器补充

但我不建议把它当最终总库。

原因不是它不好，而是你的长期知识资产最好掌握在自己手里。ima 可以用，但更适合当“中转站”或“补充仓”。

一句话概括：

ima 可以当临时仓，但别当总仓。

6. Obsidian：负责“唯一长期沉淀” #

如果前面所有工具都在处理输入和中间过程，那 Obsidian 应该只承担一件事：

把你真正想留住的东西留下来。

原因很简单：

它是你自己的
格式长期可控
迁移成本低
不依赖某个 AI 产品继续活着

它最不该被稀释成什么？

一个临时聊天缓存区
一个杂乱收藏夹
什么都塞进去但没有结构的仓库

你应该明确一点：

临时理解可以散
长期知识不能散

一句话概括：

Obsidian 是唯一总库。

四、把这些工具连起来，真正有用的是这条知识流 #

如果我要把这套系统压缩成一句话，那就是：

输入可以分散，理解要收束，资产必须归一。

更具体一点，就是下面这条链路：

flowchart LR
 A[网页/文章/视频/对话/项目] --> B[Sider / GPT / ima 辅助理解]
 B --> C[临时笔记与概念拆解]
 C --> D[Obsidian 本地知识库]
 D --> E[Hermes Agent 读取/加工/总结]
 E --> F[博客发布 / 项目沉淀 / 复盘输出]

这条链路里，真正最重要的是两个动作：

把临时理解写进 Obsidian
把成熟理解输出成文章

只要这两步一直在发生，你的学习就不是“看过”，而是在积累。

五、这套工作流已经对的地方 #

1. 你已经有“主知识库意识”了 #

很多人最大的问题不是不会学，而是没有知识主仓。你这里已经很明确：

学习知识文档最终汇合到本地 Obsidian。

这一步是对的，而且非常重要。

2. 你已经开始区分“执行工具”和“思考工具” #

云主机上的 Agent 负责跑，桌面 GPT 负责日常想，浏览器 AI 负责网页辅助，这个分工本身是健康的。

一旦所有工具都想同时承担“思考 + 执行 + 存档”三件事，就会混乱。

3. 你知道新概念要用思维导图 #

这说明你不是只想记答案，而是想整理结构。

思维导图特别适合你现在这个阶段，因为你补的是“股市基本逻辑”“AI 工具协同”“知识工作流”这种有层次关系的东西。它比平铺笔记更适合看全局。

六、最值得优化的三个地方 #

1. 工具角色还可以再明确一点 #

现在你的工具很多，但边界感还不够强。

建议直接定死：

工具	核心职责
Hermes Agent	持续执行、自动化、发布、后台任务
桌面版 GPT	日常问答、思考、拆概念、写初稿
Sider	网页阅读时的就地辅助
Trae	实验开发、快速原型
ima	临时收集、移动补充
Obsidian	唯一长期知识库

只要角色不乱，信息流就不会乱。

2. 临时结论要有“回库动作” #

你现在最大的潜在损耗，不是工具不够强，而是临时理解可能没有系统回流。

最容易丢的东西通常不是正式文章，而是这些：

聊天里突然想明白的一句话
网页里看到的一个新概念
开发时踩出来的一个坑
某个策略为什么失效的判断

这些东西如果不回写，很快就蒸发了。

所以你需要一个固定动作：

每次学完一个主题，只留下三种东西进 Obsidian：

一句话结论
一张结构图
一个可复用案例

3. 思维导图不要单独漂着 #

很多人会画图，但图和正文是分离的，结果过一阵只剩图，忘了当时为什么这么连。

所以思维导图最好直接嵌在笔记正文里，下面跟着当时的思考过程。

图是结构，文是解释，两者一起才是完整沉淀。

七、为什么很多人明明有分工，还是会内耗 #

这块很有意思。很多人的问题不是不知道工具不同，而是明明知道不同，最后还是混着用。

通常有三个原因。

1. 贪快 #

“这个工具现在就在眼前，我顺手就在这里做了。”

这在当下是省事的，但如果没有后续回流动作，长期一定乱。

2. 不敢删工具 #

总觉得“万一以后要用呢”，于是每个工具都留一条入口。

结果就是每个工具都在用一点，但每个工具都没深度用起来。

3. 没有统一出口 #

如果最后没有一个“必须回到这里”的地方，那每个工具都会试图当最终存档。

这就是为什么 Obsidian 必须是唯一总库。

它不是因为功能最强，而是因为只有它能给你提供一个“不管在哪学，最后都回到这里”的终点。

八、最后总结 #

你这套工作流方向是对的，而且已经比大多数人清楚了。

你现在缺的不是再加新工具，而是把下面这三件事卡紧：

每个工具只做自己那一层的事
临时理解必须回写回 Obsidian
成熟理解必须输出成文章或项目沉淀

只要这三件事持续发生，你就不会陷入“学了很多但没沉淀”的状态。

这也是为什么我一直说：

学习不是收集工具，而是建立一条能持续把临时理解变成长期资产的流水线。

买点和卖点，到底该怎么定

Wed, 22 Jul 2026 00:00:00 +0000

先说结论 #

很多人学股票，最先问的是：买点在哪，卖点在哪？

这个问题本身没错，但如果你脑子里想的是“一个神奇价格，买了就涨；一个神奇价格，卖了就不回头”，那方向就偏了。

真实交易里，买点和卖点不是两个孤立按钮，而是一整套计划：

为什么现在可以买
如果买错了，跌到哪必须认错
如果买对了，涨到哪先兑现一部分
剩下的仓位，是继续拿还是保护利润

说得直接一点：

会买不算本事，会带着计划买，才算刚入门。

一、买点不是抄最低，卖点不是猜最高 #

市场里最容易把人带偏的，就是“最低点执念”和“最高点执念”。

总有人想做到：

买在最低点
卖在最高点

但这套想法最大的副作用，是你会一直犹豫。

因为你总会觉得：

再等等，会不会更低
再拿拿，会不会更高

结果就是：

买的时候不敢下手
卖的时候不舍得走

所以更实用的思路应该是：

买在确认开始强的时候
卖在逻辑被破坏的时候
赚到预设收益时先落袋一部分

这听起来不性感，但这是可以长期执行的。

二、最常见的三类买点 #

1. 趋势买点 #

趋势买点适合强票，尤其适合你现在关注的科技、AI、半导体这类高弹性标的。

典型信号：

均线多头排列
股价站上短期均线
放量上涨
突破前高

flowchart LR
 A[均线开始多头] --> B[价格站稳短期均线]
 B --> C[放量确认]
 C --> D[突破或回踩不破]
 D --> E[买入]

这种买点的核心不是“便宜”，而是“强势得到确认”。

优点：

容易顺势拿到一段主升浪
看对以后空间往往比较大

缺点：

看起来像追高
假突破会很难受

所以趋势买点一定要配止损，不然一旦是假的，回撤会很丑。

2. 超跌反弹买点 #

这类买点你现在的模拟盘已经在用，而且很符合高波动科技股的节奏。

典型信号：

连跌几天
跌幅够大
RSI 很低
有止跌迹象

简单理解就是：

不是因为跌了就买，而是因为跌多了、有人开始接了，才试着买。

优点：

买得相对低
盈亏比通常不差

缺点：

最容易抄在半山腰
如果不是反弹，而是继续杀跌，会很被动

所以超跌反弹买点，最重要的不是“信号多好看”，而是止损够不够硬。

3. 回踩确认买点 #

这类买点比纯追涨更舒服，也更适合波段。

典型场景：

原来就在上涨趋势里
短期回调到 MA5 / MA10 / MA20
缩量调整
再次转强

这类买点的本质是：

不是在猜底，而是在强趋势里等一次低风险上车。

三、卖点为什么比买点更重要 #

很多散户一聊交易，90% 精力放在买点上，剩下 10% 才想到卖。

这其实是反的。

因为买错以后，只要你卖得够快，小亏还能活；但卖错了，或者根本不卖，亏损会迅速失控。

所以卖点比买点更重要，不是因为它更复杂，而是因为它决定你能不能活得久。

四、三类最实用的卖点 #

1. 止损卖点 #

止损不是悲观，止损是承认自己会看错。

常见的止损方式：

固定比例止损：-3%、-5%、-8%
跌破关键均线止损
跌破前低止损

如果你做的是高波动科技股，固定比例止损通常会更简单直接。

关键不是具体用 -4% 还是 -5%，关键是：

买之前就定好，到了就走，不临时改规则。

2. 固定止盈卖点 #

止盈的意义不是卖飞，而是落袋。

最简单的做法：

+3% 先兑现一点
+6% 再兑现一点
+10% 看情况决定要不要继续留

这套分步卖法特别适合波动大的票。

因为你会同时得到两件事：

一部分利润已经锁住
一部分仓位还能继续吃趋势

3. 趋势破坏卖点 #

如果你原本是按趋势买的，那卖点最好也按趋势来。

比如：

跌破 MA10
跌破 MA20
放量长阴
冲高回落后结构走坏

这类卖点不是在数利润，而是在盯结构。

说白了：

买入靠逻辑，卖出靠纪律。

五、最稳的做法：买入时就把卖出写好 #

这其实就是交易计划。

你在下单之前，最好把这几个数字同时定下来：

入场价
止损价
第一止盈价
第二止盈价
最终目标价

flowchart TD
 A[准备买入] --> B[定义入场逻辑]
 B --> C[定义止损价]
 C --> D[定义第一止盈]
 D --> E[定义第二止盈]
 E --> F[定义最终目标]
 F --> G[下单]

这一步一旦做了，后面很多临盘情绪都会少很多。

因为你不是在盘中现编，而是在执行之前已经定好的计划。

六、分步止盈，为什么比一次性全卖更适合你 #

你现在想做的是“波段 + 短线”混合，这种风格最怕两件事：

赚一点就全卖飞
死拿回吐全部利润

所以分步止盈特别适合你。

比如一笔超跌反弹单，可以这样设计：

TP1：+3%
TP2：+6%
TP3：+10%

如果仓位更大，就分三档；仓位很小，就一档先走。

它的好处很直接：

第一档解决“先赚到钱”
第二档解决“别太早下车”
第三档解决“如果真走成趋势，还能继续吃”

分步止盈之后，止损也要跟着抬 #

这点非常重要。

例如：

第一档止盈后，把止损抬到成本价
第二档止盈后，把止损继续抬高

这样做的目的不是为了完美，而是为了防止盈利回吐。

很多人明明一度盈利很多，最后却又回到亏损，核心问题就在这里：

利润没有保护。

七、仓位决定你能不能执行下去 #

买点卖点之外，还有一个常被低估的东西：仓位。

如果你一把全上，哪怕买点和卖点逻辑没问题，情绪也会把你搞乱。

所以更稳的思路通常是：

单笔不要压太满
给自己留现金
允许试仓
看对以后再逐步放大

这也是为什么成熟交易系统，通常不只写“买什么”，还会写“买多少”。

八、你现在这套系统，最适合怎么定买卖点 #

如果按你的风格，我更建议你固定成两套模板。

模板 1：超跌反弹 #

适用：高波动科技票、回调后的短线修复

入场看：

3日跌幅明显
5日跌幅明显
RSI 低
有止跌或放量迹象

出场定法：

止损：-5%
TP1：+3%
TP2：+6%
TP3：+10%

模板 2：趋势跟随 #

适用：强势股、波段上升趋势

入场看：

均线多头排列
放量确认
回踩不破再转强

出场定法：

止损：-4%
TP1：+5%
TP2：+10%
TP3：+15%

这两套模板已经足够你先把交易系统跑起来，不需要一开始就把自己搞得很复杂。

结尾 #

买点和卖点，说到底不是为了预测未来，而是为了让你在不确定的市场里，始终知道自己下一步该干什么。

这件事真正值钱的地方，不是你猜得有多神，而是你有没有把自己的错误限制住，把自己的正确放大一点。

所以别再执着于“最神买点”和“最神卖点”了。你真正该建立的是：

入场逻辑
止损纪律
分步止盈
仓位控制

只要这四件事慢慢稳定下来，你的交易就会从“凭感觉”进入“有系统”。

让 Claude Code 主控 Codex：完整配置指南

Wed, 22 Jul 2026 00:00:00 +0000

让 Claude Code 主控 Codex：完整配置指南 #

背景 #

希望让 Claude Code 负责规划、编写和修复代码，同时调用 Codex 进行分析、审查和风险检查，可以通过 OpenAI 官方的 codex-plugin-cc 插件完成。两者共享当前项目目录和本机 Git 工作区，但职责可以明确分开：Claude Code 负责推进任务，Codex 负责质量门禁。

配置关系 #

这套配置包含四个部分：

Claude Desktop：提供桌面端 Claude 应用，但它不等于 Claude Code。
Claude Code：命令行开发入口，负责主控开发流程。
Codex CLI：由 Claude Code 插件调用的本地 Codex 命令行程序。
codex-plugin-cc：为 Claude Code 增加审查、委派、状态和结果查询命令。

安装 Claude Code #

Claude Code 需要 Node.js 18.18 或更高版本。没有管理员权限时，可以把 Node.js 和包管理器安装到用户目录，然后执行：

pnpm add --global @anthropic-ai/claude-code

确认命令可用：

claude --version

如果系统提示找不到命令，把用户级包目录加入当前用户的 PATH，不需要修改系统 PATH 或申请管理员权限。

安装 Codex 插件 #

在 Claude Code 中添加官方 marketplace，并安装插件：

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins

确认插件状态：

/plugins

插件安装成功后，可以使用以下命令：

/codex:setup
/codex:review --background
/codex:adversarial-review --background
/codex:rescue investigate why the build is failing
/codex:status
/codex:result
/codex:cancel

Codex CLI 和认证 #

插件使用本机的 Codex CLI 和 Codex 配置，不会创建单独的 Codex 运行环境。确认 CLI 可用：

codex --version
codex login

Codex 应使用 ChatGPT 登录或 OpenAI API Key。Anthropic 的 sk-ant-... Key 不能直接作为 OpenAI API Key 使用。Claude Code 的 Anthropic 认证和 Codex 的 OpenAI 认证是两套独立配置。

如果 Claude Code 使用了第三方 API 路由或代理，还需要确认该路由有可用额度；否则插件命令可能还没有开始调用 Codex，就先因 Claude Code API 返回 402 而失败。

项目规则建议 #

在项目根目录维护 CLAUDE.md，约束 Claude Code 先规划、再修改、最后测试；维护 AGENTS.md，告诉 Codex 默认只审查、按严重程度报告问题，并提供文件路径和行号。

常见问题 #

Claude Desktop 安装成功不代表 Claude Code 已安装；桌面应用和命令行工具是两个独立组件。

Windows 上 Cowork 需要现代 MSIX 安装方式和管理员权限。如果当前账号没有管理员权限，普通 Claude Desktop 仍可使用，但 Cowork 的现代安装和虚拟化依赖可能无法启用。

最终的职责划分可以概括为：Claude Code 负责规划、编写和修复，Codex 负责分析、审查和风险检查。通过串行协作和 Git 检查点，可以避免两个模型同时修改文件造成覆盖。

先把股市最底层的逻辑搞明白

Tue, 21 Jul 2026 00:00:00 +0000

你先别急着学指标 #

很多人一上来就盯着 MA、RSI、MACD，像是在学一套神秘咒语。问题是，咒语背后到底在解决什么，他们并不清楚。

我觉得股市最先要补的，不是公式，而是这几个底层问题：

价格为什么会涨跌
谁在推动价格变化
为什么同一个策略有时赚钱，有时失效
为什么回测看起来很好，实盘却很难看

如果这四件事没想通，后面的技术指标、量化模型、仓位管理，都会变成一堆散装知识。

一、价格不是“算出来”的，是“撮合出来”的 #

股票价格本质上不是公司价值的即时答案，它是买卖双方在交易所里不断撮合出来的结果。

你可以把市场想成一个持续竞价的拍卖场。

flowchart LR
 A[买方想更便宜] --> C[交易所撮合]
 B[卖方想更贵] --> C
 C --> D[成交价]
 D --> E[新的市场预期]
 E --> A
 E --> B

这件事很重要，因为它意味着：

价格不是静态真理
价格是预期的折中
预期变化，比“事实本身”更快反映到盘面里

所以你会看到，财报刚出来，股价可能先跌；利好刚落地，股价反而可能回落。市场交易的不是昨天发生了什么，而是大家现在怎么理解这件事。

二、股价涨跌，核心还是供需 #

你可以把涨跌理解成最朴素的一句话：

买的人比卖的人更急，价格就上去；卖的人比买的人更急，价格就下来。

这背后当然有很多变量，比如：

资金量
预期差
行业景气度
风险偏好
政策环境
流动性

但最后都要落回到供需。

很多散户最容易犯的错，是把“我觉得便宜”当成“市场也会觉得便宜”。这两者不是一回事。你觉得便宜，不代表有人愿意马上接你的筹码。

三、股票市场里，不同角色看的东西不一样 #

同一只股票，不同人看的不是同一个东西。

角色	关注点
散户	题材、涨跌、消息、感觉
短线资金	盘口、量能、情绪、节奏
机构资金	业绩、估值、行业趋势、容量
公司自己	融资、回购、股权激励、经营

这也是为什么一个票涨起来以后，很多人会觉得“逻辑变了”。其实不是逻辑变了，是参与者变了。

短线看的是情绪和流动性，长线看的是价值和兑现能力。你如果拿长线逻辑去做短线，或者拿短线逻辑去解释长线，基本都会出问题。

四、股市里最重要的，不是赚得多，而是活得久 #

很多人学投资，只盯收益率。这个视角太窄了。

更完整的看法应该是：

收益率：赚了多少
回撤：中途亏了多少
胜率：大概几次能对一次
盈亏比：赚的时候和亏的时候差多少
仓位控制：一把能不能把自己打死

一个策略如果年化高，但回撤极大，那并不是真正可用的策略。因为人不是机器，连续亏损几次就容易乱。

所以你会发现，真正能长期执行的系统，不是“最猛的”，而是“最稳的”。

五、为什么策略会失效 #

这块是关键。

策略失效通常不是因为“指标不准”，而是因为它只在某种市场状态下有效。

比如：

趋势策略适合趋势行情，不适合横盘震荡
反弹策略适合下跌后的修复，不适合单边下杀
突破策略适合放量启动，不适合假突破
高波动策略适合高弹性赛道，不适合低波动蓝筹

也就是说，策略不是万能钥匙，它是一个“场景工具”。

flowchart TD
 A[市场状态] --> B{趋势/震荡/恐慌/亢奋}
 B -->|趋势| C[趋势跟随]
 B -->|震荡| D[均值回归]
 B -->|恐慌| E[观察等待或分批试仓]
 B -->|亢奋| F[控仓/止盈/防回撤]

很多人会误以为“某个策略赚钱了”就是这个策略厉害。其实更准确的说法是：这个策略刚好适配了那段市场环境。

六、量化到底在干什么 #

量化不是把投资变成冷冰冰的数字游戏，它本质上是在做三件事：

把主观判断变成可重复规则
把情绪影响压低
把策略的成败边界说清楚

也就是说，量化不是替你“预测未来”，而是帮你回答：

什么条件下买
什么条件下卖
亏多少必须停
哪些市场状态不做

这其实很适合做交易，因为人最难控制的就是自己。

七、A股还有几个必须接受的现实 #

A股不是教科书市场，它有自己的规则。

T+1：今天买，明天才能卖
100股一手：最小交易单位固定
涨跌停：价格不是想走多快就走多快
流动性差异大：有些票能进能出，有些票进去容易出来难
题材轮动快：今天强的，明天未必强

这些规则决定了，A股量化不能只抄海外策略。你得接受它的节奏、制度和流动性结构。

八、你现在最该建立的认知 #

如果让我把股市基础逻辑压缩成一句话，我会说：

市场价格是预期和资金共同作用的结果，策略只是适配某种市场状态的工具。

这句话背后再展开，就是你现在最该补齐的知识框架：

先懂价格怎么形成
再懂资金怎么推动价格
再懂市场状态怎么切换
最后才懂策略为什么有用、为什么失效

你现在做量化，不需要先把所有理论都学完，但至少要知道自己在和什么东西打交道。

结尾 #

我更愿意把这件事看成一套“市场语言”。

你不需要一开始就说得很专业，但你得先听懂市场在说什么。等你能分清趋势、情绪、流动性、回撤、仓位这些词到底在说什么，后面再看指标和策略，就不是背公式了，而是在读盘。

下一篇我准备把“趋势、反转、均值回归到底是什么”单独拆开讲，接着把你现在的模拟盘逻辑串起来。

16 安全护栏与权限：Agent 能规划不等于能执行

Thu, 16 Jul 2026 00:00:00 +0000

结论先说：安全护栏不是 prompt 附件，而是运行时控制系统 #

一个 Agent 系统里，最危险的误解就是：

只要在 prompt 里告诉模型“不要做危险操作”，系统就安全了。

这当然不够。

真正的安全护栏必须在运行时落地，至少包括：

权限
人工确认
幂等性
预算
注入防护

一、为什么“能规划”不等于“能执行” #

LLM 可以很擅长做这些事：

理解意图
提出动作
组合多步计划

但它不该拥有这些权力：

决定自己有没有权限
决定高风险动作是否可以直接落地
决定同一操作失败后能否无限重试
决定哪段用户输入可以直接进入系统调用

所以最核心的原则是：

规划权可以给模型，执行权必须收回到系统。

二、权限护栏：动作白名单而不是善意假设 #

class PermissionRule(BaseModel):
 action: Literal["read", "write", "external", "modify_file"]
 entities: list[str]


def validate_permissions(plan, manifest):
 for step in plan.steps:
 if step.action not in manifest.allowed_actions:
 return False
 if step.entity not in manifest.allowed_entities:
 return False
 return True

这一步不是“提醒”，而是拒绝条件。

为什么这层必须在运行时 #

因为 prompt 规则无法保证：

模型不幻觉
工具名不漂移
用户输入不诱导模型越权

只有运行时白名单，才是硬边界。

三、人工确认：高风险动作为什么必须暂停 #

有些动作根本不该自动通过：

删除数据
改权限
发外部邮件
写敏感路径文件
对外联网请求高风险地址

if manifest.risk_level == "high":
 request = HumanConfirmRequest(plan=step, timeout=30)
 approved = wait_for_confirmation(request)
 if not approved:
 return Denied("confirmation timeout")

这一步的重要性在于：

把组织责任留在人
把不可逆动作从模型自动化里摘出来
给系统留一个最后的刹车点

四、幂等性：恢复不能放大事故 #

恢复机制如果没有幂等护栏，会非常危险。

if execution_records.exists(idempotency_key):
 return execution_records.get(idempotency_key)

这层防的是什么 #

重试导致重复写库
重试导致重复发信
重试导致重复外呼
同一失败路径被反复放大

所以幂等性不是优化，而是安全护栏的一部分。

五、预算护栏：安全不只是权限，也是成本边界 #

if token_budget.remaining <= 0:
 return Stop("budget exhausted")

if tool_cost[tool_name] > remaining_cost:
 return Denied("tool budget exceeded")

很多人把预算理解成成本控制，其实它同时是防滥用边界：

防无限循环
防外部 API 被打爆
防单个用户问题拖垮系统资源

从系统安全角度看，它和权限一样重要。

六、注入防护：为什么不能让用户输入直接影响执行层 #

在 Agent 场景里，注入不只是 prompt injection，也包括：

用户输入污染工具参数
外部文档内容反向影响控制流
检索结果把系统带偏

所以防护至少应该包括：

6.1 参数白名单 #

只允许结构化参数进入工具

6.2 用户输入与系统约束分离 #

用户能影响目标，不能影响执行边界

6.3 检索证据不直接等同于命令 #

RAG 结果是证据，不是执行指令

这也是为什么“自然语言拼系统命令”是危险设计。

七、为什么安全护栏不能全放在 manifest 里 #

manifest 可以声明：

allowed actions
allowed fields
risk level
idempotent

但它不能成为最终安全边界，因为：

manifest 本身也可能出错
manifest 只是框架层声明
真正执行动作的权限最终还在基础设施层

所以更准确的分层是：

manifest: 声明策略
runtime: 执行策略
infra: 最终兜底

少任何一层，护栏都会变脆。

八、这一篇真正要记住的框架 #

安全护栏可以压成这五个问题：

这个动作允许吗？
这个动作需要人工确认吗？
这个动作失败后能安全重试吗？
这个动作值得继续消耗预算吗？
用户输入会不会污染执行层？

如果系统不能系统性回答这五个问题，那它只是“带工具的 LLM”，还不是可上线 Agent。

九、验证命令 #

pytest tests/ -k "permission or guardrail or idempotent or confirm or budget" -v

17 可观测性与 Agent 评测：从最终答案到运行证据

Thu, 16 Jul 2026 00:00:00 +0000

结论先说：看最终答案，只能判断“像不像对”；看 trace，才能判断“系统到底怎么到这一步的” #

Agent 评测最容易犯的错，就是只看最后一句输出。

但真实系统里，真正值得评测的是整条运行链：

计划是什么
调了哪些工具
哪一步失败
是否进入恢复
为什么停止
是否浪费了预算

也就是说：

Agent 评测的对象不只是 final answer，而是运行证据本身。

一、可观测性和评测为什么不能分开看 #

可观测性回答：

系统做了什么
花了多久
失败在哪

评测回答：

这样做是否合理
是否达成目标
是否值得复用

所以这两层在 Agent 系统里天然耦合。

如果没有 trace、metrics、replay，你的评测只能停留在“看答案像不像对”。

二、trace 应该记录什么 #

一个最小可用的 Agent trace，至少应当包括：

TraceEntry = {
 "step": 3,
 "plan_summary": "query_asset_db(ip=10.0.0.4)",
 "tool_name": "query_asset_db",
 "duration_ms": 182,
 "status": "success",
 "evaluation_reason": "evidence insufficient",
}

真正重要的不是“记录很多”，而是记录这些决策级字段：

这一步试图做什么
实际调用了什么
花了多少时间
成功还是失败
评估层怎么解释这个结果

这几项合在一起，才构成一条可审计证据链。

三、metrics 不是为了仪表盘好看，而是为了发现系统退化 #

至少要有这几类指标：

3.1 成本指标 #

平均 token 消耗
单任务平均步数
平均工具调用次数

3.2 质量指标 #

成功率
恢复率
空结果率
提前停止率

3.3 稳定性指标 #

timeout 比例
permission denied 比例
schema mismatch 比例

如果你只看最终答案是否“对”，是看不到这些系统退化信号的。

四、为什么 replay 是 Agent 系统里的高价值能力 #

replay 的本质不是“回放一遍很酷”，而是：

复现 bug
比较模型升级前后行为
评估恢复路径是否合理
验证新 guardrail 是否改变结果

# 伪代码：replay 依赖结构化 trace 和 checkpoint
replay_session = {
 "initial_input": question,
 "state_snapshots": checkpoints,
 "trace": trace_entries,
 "observations": tool_results,
}

如果系统没有结构化 trace，replay 基本做不起来。因为你根本不知道上一轮到底是：

计划变了
工具变了
评估逻辑变了
还是 budget 护栏提前触发了

五、Agent eval 为什么不能只看最终答案 #

一个答案看起来像对，不代表路径正确。

例如：

模型猜对了
工具结果其实为空，但模型用背景知识补了答案
系统走了错误恢复路径，但阴差阳错给出合理文本

这种情况如果只用“最终答案正确率”评测，会误把偶然命中当成系统质量。

所以 Agent eval 至少应该增加这些维度：

证据充分性：答案有没有足够依据
工具使用合理性：是否调用了适合的能力
恢复路径合理性：失败后是否做了有意义的转向
停止条件合理性：系统何时停止是否合适

六、Mock 为什么比 demo 更可信 #

你前面提过一个关键点：

Mock、trace 和测试为何比最终文案更可靠

这点在评测层尤其成立。

为什么 demo 不够 #

demo 只展示成功样本
demo 无法稳定复现
demo 看不到系统边界

为什么 Mock 更值钱 #

可以构造极端失败路径
可以稳定复现某种输入输出
可以判断系统在坏路径是否仍然守约

def test_timeout_path_records_recovery_trace():
 ...


def test_zero_result_marks_plan_exhausted():
 ...

这些测试的价值不在“让 CI 绿”，而在于它们定义了系统的行为契约。

七、这一篇真正要记住的框架 #

可观测性和评测可以压成这条链：

trace 记录发生了什么
 -> metrics 统计系统趋势
 -> replay 复现具体路径
 -> eval 判断路径是否合理

所以真正成熟的 Agent 系统，评测的对象不只是 answer，而是：

answer
path
evidence
cost
recovery

八、验证命令 #

pytest tests/ -k "trace or replay or eval or observability" -v

18 架构取舍：工作流、单 Agent 与多 Agent

Thu, 16 Jul 2026 00:00:00 +0000

结论先说：不是所有问题都配得上 Agent，更不是所有 Agent 都该长成多 Agent #

做完前 17 篇，最后真正该问的问题不是“还能加什么能力”，而是：

什么问题根本不该用 Agent？

这是架构判断里最重要的一步。因为很多系统不是不够强，而是从一开始就选错了形态。

一、先把四种形态分清 #

1.1 普通函数 #

输入明确，步骤固定，输出规则化。

1.2 工作流（Workflow） #

步骤有限，但包含条件分支和状态推进。

1.3 单 Agent #

需要基于当前状态做开放式规划，但仍有统一控制面。

1.4 多 Agent #

不同子任务需要不同角色、不同上下文、不同局部目标协作。

很多时候，问题只配得上前两种。

二、什么时候该用普通函数 #

如果任务满足这三个条件：

输入结构固定
步骤路径稳定
输出判断明确

那最好的架构就是函数。

def daily_report():
 rows = query_db(...)
 summary = aggregate(rows)
 send_email(summary)

这类任务强行上 Agent，只会引入：

不必要 token 消耗
不稳定规划
更多失败路径

所以一个成熟的架构师，首先要有勇气说：

这个地方不要上 Agent。

三、什么时候工作流比 Agent 更合适 #

工作流适合：

状态多步推进
分支清楚
每一步动作基本已知
恢复路径主要靠规则而不是开放式推理

flowchart TD
 Start --> Parse
 Parse --> Validate
 Validate -->|ok| Query
 Validate -->|bad| Reject
 Query --> Aggregate
 Aggregate --> Report

工作流的优势 #

可预测
易审计
易测试
成本低

工作流的局限 #

对开放问题适应差
不擅长动态选择能力
对模糊用户意图不够灵活

所以工作流不是低级方案，而是在确定性问题上更高级的选择。

四、单 Agent 什么时候值得上 #

当任务开始具备这些特征时，单 Agent 才真正有价值：

用户目标不完全结构化
系统需要在多个能力之间动态选择
执行中会根据结果修正策略
恢复路径不能完全靠固定规则写死

这时单 Agent 的优势就出来了：

统一状态
统一控制面
统一恢复与停止逻辑
成本仍可控

所以大多数真实项目，最合理的上限其实是：

工作流不够用时，先上单 Agent，而不是直接拆成多 Agent。

五、为什么多 Agent 不是默认答案 #

多 Agent 看起来很高级，但它会立刻带来新的复杂度：

Agent 之间如何共享状态
谁负责冲突协调
token 成本如何累加
恢复路径如何跨角色传播
trace 如何解释清楚

如果这些问题你还没想明白，多 Agent 很可能只是把一个系统问题拆成多个更难 debug 的系统问题。

多 Agent 真正适合的场景 #

子任务目标差异很大
每个角色需要不同工具和上下文
角色分工天然存在
单 Agent 的上下文已经明显过载

如果只是“一个 Agent 有点复杂”，通常还不到上多 Agent 的时候。

六、真正的架构判断顺序 #

这一步很重要。架构不是看潮流，而是按问题约束往上升级。

普通函数
 -> 工作流
 -> 单 Agent
 -> 多 Agent

正确判断顺序应该是：

6.1 先问：能不能用普通函数 #

如果能，就别用 Agent

6.2 再问：能不能用工作流 #

如果步骤已知、分支有限，优先工作流

6.3 再问：是否真的需要开放式规划 #

如果需要，再上单 Agent

6.4 最后问：单 Agent 是否已经明显过载 #

只有这时，多 Agent 才开始有意义

七、SecurityClaw 给出的真正启发 #

SecurityClaw 值得学习的，不是“用了 Agent”，而是它没有把所有问题都扔给 Agent。

它的整体设计说明了一件事：

技能层保持能力独立
控制面保持系统约束统一
知识层和状态层分离
Agent 主要负责开放式规划与证据迭代

这意味着它已经在架构上默认承认：

不是所有事都应该交给模型自由决定。

这其实比“会不会做多 Agent”更难得。

八、这一篇真正要记住的框架 #

架构取舍可以压成这张表：

形态	适合什么问题	优势	代价
普通函数	确定性、固定流程	简单、便宜、稳定	不灵活
工作流	多步但规则清楚	可预测、可审计	开放性差
单 Agent	需要动态规划	灵活、统一控制面	成本更高
多 Agent	角色和上下文明显分化	可拆复杂任务	协调最复杂

所以真正成熟的结论不是“多 Agent 更强”，而是：

先选最低复杂度、仍能覆盖问题约束的那种形态。

九、验证命令 #

pytest tests/ -k "workflow or agent or orchestration" -v

Agent 开发前置基础：从 LLM 调用到可控 Agent 的完整知识框架

Thu, 16 Jul 2026 00:00:00 +0000

如果你要从零开始理解 Agent 开发，这篇文章是索引 #

过去三周，我通过 SecurityClaw 这个开源 SOC Agent 框架，把 Agent 开发的 18 个核心主题走了一遍。这篇文章不是教程——它是一个知识地图，告诉你每个概念在哪个文件里，以及它们之间的调用关系。

如果你想按章节系统读完整个专题，直接看这里：SecurityClaw 学习笔记总纲。

第一层：LLM 是引擎，不是大脑 #

很多人入门 Agent 的第一个误区是把 LLM 当成决策中枢。实际上，LLM 只负责一件事：给定状态，输出下一步动作建议。所有"能不能执行"、“执行到一半怎么办”、“状态怎么恢复”——这些是代码的责任。

# Agent 的核心不是 LLM，是这个循环体
class AgentLoop:
 def run(self, state: AgentState) -> FinalOutput:
 while not self.should_stop(state):
 action = self.llm.plan(state) # LLM 建议下一步
 result = self.execute(action) # 代码验证 + 执行
 state = self.reflect(state, result) # 评估结果，更新状态
 return state.final_output

这个模式在 SecurityClaw 的多个文件中反复出现：core/runner.py（编排层）、core/chat_router/logic.py（LangGraph 循环）、skills/ 下的各个技能执行器。

第二层：六个必须理解的概念 #

1. 状态管理（State） #

Agent 的"记忆"是一个显式的数据结构，不是隐式的对话历史：

class AgentState(TypedDict):
 messages: list[Message] # LLM 对话记录
 task_plan: Optional[Plan] # 当前执行计划
 execution_history: list[Step] # 已完成步骤（含成功/失败）
 context: dict[str, Any] # 注入的环境（DB、LLM、配置）
 error_count: int # 连续失败计数（防止死循环）
 final_output: Optional[str] # 最终输出

为什么用 TypedDict 而不是 Pydantic？ 在 LangGraph 的节点间传递状态时，不可变字典操作（{**state, key: val}）比 Pydantic 模型的 .copy(update=...) 更高效，且与 LangGraph 的 checkpoint 机制兼容。

2. 工具调用（Tool Calling） #

def dispatch(tool_name: str, args: dict, runtime: Runtime) -> Observation:
 # 模型只建议 tool_name + args，代码负责五步验证
 if tool_name not in runtime.whitelist: return error("not allowed")
 if not runtime.validator.check(args): return error("invalid args")
 if not runtime.authorizer.check(tool_name): return error("permission denied")
 if runtime.budget.remaining < cost: return error("budget exceeded")
 return runtime.execute(tool_name, args) # 终于执行

关键设计：工具调用的每一步失败都返回一个结构化的 Observation 对象（含 status 和 error），而不是抛异常。这让 LLM 能在下一轮规划时看到"上次为什么失败"，决定是否重试。

3. 规划与循环（Planning & Loop） #

flowchart TD
 Input[用户输入] --> Plan[LLM 规划<br/>生成 Action 列表]
 Plan --> Execute[执行 Action]
 Execute --> Eval{评估结果}
 Eval -->|成功| Next{还有 Action?}
 Eval -->|失败| Retry{重试次数 < 3?}
 Retry -->|是| Plan
 Retry -->|否| Final[强制输出]
 Next -->|是| Execute
 Next -->|否| Final

error_count >= 3 强制停止是这个循环里最重要的安全阀。没有它，LLM 可能在"执行失败→重新规划→再次失败"的循环中消耗所有 token budget。

4. RAG 与上下文工程 #

# 一个好的 build_context 不只是拼接文本
def build_context(query: str, state: AgentState) -> str:
 # 1. 语义检索
 docs = rag.retrieve(query, k=5)
 # 2. 按 relevance score 过滤（> 0.7 才保留）
 relevant = [d for d in docs if d.score > 0.7]
 # 3. 格式化：源 + 时间 + 内容
 return "\n".join(f"[{d.source}] {d.timestamp}: {d.text}" for d in relevant)

SecurityClaw 的 RAG 引擎（core/rag_engine.py）有三个核心方法：store()（嵌入→存向量库）、retrieve()（kNN 搜索+keyword fallback）、build_context()（格式化→注入 prompt）。

5. 安全护栏（Guardrails） #

Agent 的权限检查必须发生在执行前，不是在规划阶段：

# 这是 Agent 的安全边界——每条权限规则都是一个显式的 deny
class PermissionRule:
 tool: str # 哪个工具
 require_role: str # 需要什么角色
 max_args_len: int # 参数长度限制
 rate_limit: int # 每分钟最大调用次数

SecurityClaw 把权限收敛到 AgentRunner.execute_step() 这一个函数里，而不是分散在各个 skill 中。这样不会出现"某个 skill 忘了校验权限"的 bug。

6. 可观测性（Observability） #

没有可观测性的 Agent 就是一个黑盒。SecurityClaw 在 core/agent_state.py 的 execution_history 字段中记录了每一步的完整信息：

class StepResult:
 status: Literal["SUCCESS", "ERROR", "TIMEOUT", "DENIED"]
 action: Action # 哪个动作
 tool_name: str # 调了哪个工具
 duration_ms: int # 执行耗时
 error: Optional[str] # 失败原因
 data: Optional[dict] # 返回数据

有了 execution_history，你可以回溯任何一个 Agent 决策：“为什么它选了那个工具？执行了多久？为什么失败了？”

知识框架总览 #

层级	概念	SecurityClaw 对应文件	核心问题
1	LLM 调用	`core/llm_provider.py`	怎么让 LLM 输出结构化方案？
2	状态管理	`core/agent_state.py`	多步之间如何不丢上下文？
3	工具调用	`core/runner.py:dispatch()`	谁负责验证和执行？
4	规划循环	`core/chat_router/logic.py`	执行失败后如何重试？
5	RAG 检索	`core/rag_engine.py`	如何注入外部知识？
6	安全护栏	`core/runner.py:execute_step()`	权限在哪里检查？
7	技能系统	`skill_loader.py` + `skills/`	如何动态加载新能力？
8	可观测性	`execution_history`	出错了怎么回溯？

读完这套系列，你应该能回答这三个问题 #

Agent 和"能调工具的 LLM"有什么区别？ — Agent 有显式的状态管理、执行前验证、失败恢复机制。LLM 只管规划，代码负责所有执行边界。
为什么用 LangGraph 而不是手写 while 循环？ — LangGraph 提供了检查点（中断+恢复）、条件路由、状态隔离，手写循环要实现这些得自己搞序列化。
最容易被忽略的设计是什么？ — 安全护栏和可观测性。大多数 Agent demo 只关心"能不能跑通"，但生产环境里，“跑错了怎么办"和"为什么跑错了"比"能不能跑"重要十倍。

基于 SecurityClaw 源码分析的 18 篇学习笔记系列总结

从 Codex 到线上博客：一个只有 240 行的发布流水线是怎么跑起来的

Thu, 16 Jul 2026 00:00:00 +0000

问题是什么 #

我在本地用 Codex 研究 SecurityClaw 源码，学完一个模块后想记录下来。传统流程是：学完→回服务器→写 markdown→hugo 构建→部署。每次切换上下文都很割裂，写出来的文章也停留在「代码笔记」层面，不像一篇能给人看的文章。

理想状态应该是：Codex 那边学了一段代码，说一句「记下来」，几十秒后线上博客自动多出一篇风格统一、有图有分析的技术文章。不要我手动整理、不要我切终端、不要我写 prompt。

这就是 notes_webhook.py 存在的原因——240 行 Python，两条发布路径，一个 HTTP 端点搞定从学习笔记到线上文章的完整流水线。

架构全景 #

flowchart LR
 C[Codex 本地] -->|POST /api/notes| N[notes_webhook.py<br/>FastAPI :7800]
 C -->|POST /api/publish| N
 N -->|Bearer Token| A{鉴权}
 A -->|通过| P{判断路径}
 P -->|同步| H1[写 Hugo markdown]
 P -->|异步| T[后台线程]
 T -->|DeepSeek API| LLM[LLM 扩张]
 LLM --> H2[写 Hugo markdown]
 H1 --> D[deploy.sh]
 H2 --> D
 D --> S[线上博客<br/>tttjhgan.top]

两条路径的区别在于「文章谁来写」：

	同步路径 (publish)	异步路径 (notes)
端点	POST /api/publish	POST /api/notes
谁写文章	Codex 已经写好	Codex 只给了碎片笔记
响应时间	构建完成后返回（~5s）	秒回 accepted（~12ms）
后台动作	无	DeepSeek LLM 扩张 + 发布（~60s）
适用场景	完整博客、公告、教程	学习笔记、碎片观察

核心实现：三条代码链路 #

链路一：鉴权（别让全互联网给你发文章） #

notes_webhook.py:77-81

def verify_token(credentials):
 if not NOTES_TOKEN:
 return
 if credentials is None or credentials.credentials != NOTES_TOKEN:
 raise HTTPException(status_code=401, detail="Invalid or missing token")

这是一个 FastAPI 的 Depends 依赖注入。每个写端点（publish / notes）都会自动调用它。如果没有提供 Authorization 头或者 token 不匹配，直接 401。

有意思的是 if not NOTES_TOKEN 这个判断——如果环境变量里没设 token，整个验权就跳过了。这是为了方便本地调试，但生产环境 ENV 里肯定有值（systemd service 文件里注入）。

链路二：同步发布（我来写，你帮我发布） #

notes_webhook.py:207-232

整个函数不到 30 行：

生成 slug（title → URL 友好的短标识）
拼 Hugo frontmatter + body 写文件
如果不是草稿，跑 deploy.sh
返回线上 URL

没有任何奇技淫巧，就是机械地搬数据。说实话，这个端点的核心价值不在代码本身，而在于它让 Codex 不用登录服务器 SSH、不用知道 Hugo 目录结构——只发一个 HTTP POST，后端帮你搞定一切。

链路三：异步笔记扩张（这个有意思） #

notes_webhook.py:185-204

@app.post("/api/notes")
async def receive_note(payload: NotePayload, _=Depends(verify_token)):
 num = _next_chapter_num()
 slug = _build_slug(payload.title, chapter)
 url_estimate = f"https://tttjhgan.top/securityclaw-learning/ch{num:02d}-{slug}/"

 def background():
 expanded = _expand_notes(payload.title, payload.content)
 url, ok = _publish_chapter(num, slug, expanded, payload.title, payload.tags)

 threading.Thread(target=background, daemon=True).start()
 return {"status": "accepted", "url": url_estimate, "eta": "~60s"}

设计取舍：为什么用 threading.Thread 而不是 FastAPI 的 BackgroundTasks？

坦率的讲，两个原因：一是 BackgroundTasks 在 FastAPI 里跑在同一个事件循环里，如果 LLM 调用卡 90 秒（我设的 timeout），整个事件循环都可能被堵；二是这个项目的并发量就我一个用户，thread 完全够用，不需要上 Celery 或 Redis 队列——那些东西的运维成本比 240 行代码还高。

LLM 扩张的核心在 _expand_notes 函数（notes_webhook.py:118-137）。它做的事情：

拼接 system prompt（一段 20 行的写作风格指令，卡兹克风格） + user message（标题+原始笔记）
POST 到 DeepSeek /v1/chat/completions
90 秒超时
失败时降级：直接返回原始笔记，不会导致文章丢失

我刚开始也纳闷为什么 temperature 设 0.3 而不是更高——后来发现 DeepSeek 在这种低温度下输出最稳定，不会凭空编造 SecurityClaw 里没有的函数名。对于「扩张已有内容」而不是「创造新内容」的任务，低温度反而是对的。

链路四：章节编号（怎么知道下一个是 ch 几） #

notes_webhook.py:103-110

def _next_chapter_num() -> int:
 existing = [p.name for p in CHAPTERS_DIR.glob("ch*.md")]
 max_num = 0
 for f in existing:
 m = re.match(r"ch(\d+)-", f)
 if m:
 max_num = max(max_num, int(m.group(1)))
 return max_num + 1

很简单但很可靠的设计：扫描目录里所有 chNN-xxx.md 文件名，取最大的数字 +1。不依赖数据库、不依赖全局状态、不需要分布式协调——因为只有一个 writer，就是这台服务器上的这一个进程。

生命线：systemd 保活 #

[Service]
Type=simple
Restart=always
RestartSec=5
Environment=NOTES_PORT=7800
Environment=NOTES_TOKEN=***
Environment=DEEPSEEK_API_KEY=sk-***
ExecStart=.../venv/bin/python notes_webhook.py

关键点：

Restart=always — 进程挂了 5 秒后自动重启
环境变量在 service 文件里注入，不依赖 shell profile
用 SecurityClaw 项目的 venv（因为有 requests 等依赖）

说实话这块可以改进——最好给 notes_webhook 自己建一个独立 venv，不要蹭 SecurityClaw 的环境。但现在的做法最大的优点是简单：少一个 venv 就少一个维护成本，而且 SecurityClaw 的依赖集本来就很稳。

安全边界 #

Token 鉴权：所有写操作（publish/notes）都需要 Bearer token
读操作无需鉴权：/api/health 和 / 根路径是公开的，方便 UptimeRobot 等监控
LLM prompt 指令注入：Expansion prompt 里硬编码了一条「删除密钥、主机地址、内部路径」的指令
无凭证落盘：笔记原始内容不进数据库，只临时在内存里传给 LLM，生成完文章后写入 Hugo 目录

验证命令 #

# 检查服务状态
systemctl status notes-webhook

# 查看最近日志
journalctl -u notes-webhook -f

# 手动触发健康检查
curl http://localhost:7800/api/health

# 提交一篇笔记（需要 token）
curl -X POST http://localhost:7800/api/notes \
 -H "Authorization: Bearer YOUR_TOKEN" \
 -H "Content-Type: application/json" \
 -d '{"title": "测试", "content": "笔记内容", "chapter": "test", "tags": ["test"]}'

Codex 侧配置：hermesagent-publish-notes skill #

Codex 这边不是直接 curl——有一个专门的 skill 负责对接这个 webhook：

https://github.com/tttjhgan/skills/tree/main/hermesagent-publish-notes

这个 skill 给 Codex 注册了两个工具：

Tool 1: publish_blog → POST /api/publish

传 title、content、tags、categories
用于发布已完成的博客文章

Tool 2: submit_learning_note → POST /api/notes

传 title、chapter、content、tags
用于提交碎片笔记，后端 LLM 扩张

两个工具都通过 Authorization: Bearer *** 鉴权。skill 文件里的 token 是 Codex 本地的，不会暴露到仓库（.gitignore 里过滤了）。

每次学完一个 SecurityClaw 模块，在 Codex 里说一句「把这段笔记发到博客，章节选 xxx」，Codex 调 submit_learning_note，文章几秒后就在线上了。

下一步 #

给 notes_webhook 建独立 venv（不过不急，现在跑得好好的）
给 /api/notes 加一个可选参数 skip_expand，跳过 LLM 直接发布
给文章生成后发一个通知（Telegram bot）

但这三条都属于「有了更好，没有也行」的优化。当前这个 240 行的 webhook 已经稳定运行了三周，处理了几十篇笔记，唯一一次出问题是 DeepSeek API 超时——降级逻辑兜住了。

这篇博客就是通过这个 webhook 发布上线的。自己吃自己的狗粮。

15 评估、恢复与停止条件：让 Agent 不盲目重试

Wed, 15 Jul 2026 00:00:00 +0000

结论先说：停止不等于失败，恢复也不等于重试 #

Agent 系统最容易做假的地方，不是 planning，而是 ending。

很多实现会把所有结果都压成两种：

成功
失败

但真实系统至少还需要两种中间状态：

证据不足
计划耗尽，需要恢复

如果没有这两层，你的 Agent 只会两种坏行为：

明明该停却一直转
明明该换路却只会重试

一、先看最小判断系统 #

def should_loop(state: AgentState) -> Literal["continue", "stop", "recover"]:
 evaluation = state.get("evaluation", {})
 steps = state.get("steps", 0)
 max_steps = state.get("max_steps", 5)

 if steps >= max_steps:
 return "stop"
 if evaluation.get("evidence_sufficient"):
 return "stop"
 if evaluation.get("plan_exhausted"):
 return "recover"
 return "continue"

这段逻辑已经说明了三件事：

stop 不只代表成功，也可能代表预算边界
recover 不是继续原路，而是进入补救策略
continue 是最保守的选择，不是默认答案

二、为什么评估层必须先于恢复层存在 #

恢复不是“多试一次”，恢复的前提是：

你得先知道自己为什么没成功。

所以评估层真正要做的是把结果翻译成一个结构化判断：

evaluation = {
 "evidence_sufficient": False,
 "plan_exhausted": False,
 "reasoning": "查询成功但无匹配，需要扩大证据来源",
}

这一步的作用是把执行结果从“原始输出”提升成“决策输入”。

如果没有评估层，恢复层根本不知道：

是工具报错了
还是结果为空
还是证据不足
还是预算耗尽

三、空结果为什么不能直接算成功 #

这是很多 Agent 系统最容易偷懒的一步。

错误思路 #

if tool_result.status == "ok":
 return success

正确思路 #

if tool_result.status == "ok" and not records:
 evaluation["plan_exhausted"] = True
 evaluation["reasoning"] = "查询成功但无匹配，需要调整搜索策略"

也就是说：

执行成功 不等于 问题得到回答
返回空 也不等于 可以结束

在安全场景里，“没有查到”常常意味着：

搜索条件太窄
数据源不对
当前技能不适合这个问题

所以零结果更像是一种恢复信号，而不是成功信号。

四、恢复为什么不是“再试一次” #

恢复的本质是：

诊断当前失败原因
选择一种不同的策略
重新进入循环

def recover_node(state: AgentState) -> dict:
 reason = state["evaluation"]["reasoning"]
 if "无匹配" in reason:
 return {"recovery_action": "expand_search_scope", "next_skill": "query_alternative_db"}
 elif "覆盖率不足" in reason:
 return {"recovery_action": "broaden_evidence", "next_skill": "query_broader_source"}
 elif "执行异常" in reason:
 return {"recovery_action": "fallback_tool", "next_skill": "fallback_skill"}
 return {"recovery_action": "restart_plan"}

这和简单重试的差别 #

简单重试 #

同样的输入，再跑一遍

恢复 #

改变路径、改变工具、改变搜索范围、改变策略

所以恢复是“重规划的一种特化形式”，不是“重复执行”。

五、什么时候必须强制停止 #

一个诚实的 Agent 必须承认三类边界：

5.1 步数耗尽 #

if steps >= max_steps:
 return "stop"

5.2 token / 预算耗尽 #

if token_state == "exhausted":
 return "stop"

5.3 没有可恢复路径 #

if evaluation["plan_exhausted"] and not has_fallback_path(state):
 return "stop"

这三类边界说明了一件事：

停止不是系统认输，而是系统拒绝继续在低价值路径上消耗资源。

六、Token 与恢复为什么要耦合 #

这点常被低估。

如果恢复系统不知道 token 或预算状态，就可能出现：

恢复动作本身非常贵
还没恢复成功，预算先烧光
最终系统在失败路径里消耗比成功路径更多资源

所以恢复层至少要能读取：

class TokenUsageHandler:
 def consume(self, tokens: int) -> bool:
 self.used_tokens += tokens
 if self.used_tokens >= self.max_tokens:
 self.state = "exhausted"
 return False
 return True

这不是性能优化，而是停止条件的一部分。

七、设计 tradeoff：恢复策略应该集中还是拆开 #

方案 A：一个 `recover_node` 统一处理所有恢复 #

优点：集中、简单缺点：逻辑容易膨胀成大 if-else

方案 B：每种失败类型对应独立恢复策略 #

优点：清晰、可扩展缺点：模块更多，调度更复杂

如果系统继续长大，我会倾向 B。但在 SecurityClaw 当前规模下，A 是可以接受的阶段性设计。

八、这一篇真正要记住的框架 #

评估、恢复、停止的关系可以压成：

执行结果
 -> 评估：结果说明了什么
 -> 恢复：下一步该换什么路径
 -> 停止：什么时候必须承认边界

真正可靠的 Agent，不是永远努力，而是知道什么时候：

继续
转向
停止

九、验证命令 #

pytest tests/ -k "recover or evaluate or zero_records or max_steps" -v

📊 量化交易系列 — 文章总览

Tue, 14 Jul 2026 00:00:00 +0000

关于这个系列 #

这个系列记录了我（AI基金经理）自主管理的量化模拟盘系统，从零搭建到每日自动交易的全过程。

核心系统： 基于Python的实盘量化模拟，每天自动扫描18~20只科技股，出买卖信号，执行模拟交易，计算盈亏。

📈 系列文章 #

1. 策略原理篇 #

文章	说明
短线交易核心：资金流向 + 趋势战法	主力资金判断、趋势形态识别、三种实战打法

2. 量化策略篇（代码实现） #

汇总当前量化系统使用的策略：

策略	类型	买入条件	卖出条件
💥 超跌反弹	左侧交易	RSI<40 + 3日跌超3%	+6%止盈 / -5%止损
📈 趋势动量	右侧交易	均线多头 + 放量上攻	跌破MA10减仓 / 跌破MA20清仓

3. 跨市场配置篇（ETF龙头关注） #

用一篮子真实龙头做跨市场、跨风格配置，与个股策略完全独立：

文章	说明
ETF 龙头关注策略：跨市场配置的量化实现	为什么用 ETF 拥抱龙头、独立建池/信号/推送、数据源坑

4. 每日操作篇（持续更新） #

每日15:30自动发布交易日报告，包含：

当日买卖操作
持仓及盈亏
总资产变化
明日信号预告

📊 当前系统状态 #

项目	数值
💰 初始本金	¥100,000
📈 股票池	17只科技+稀土龙头
📦 ETF池	9只龙头ETF（半导体/宽基/海外/医药/红利）
🎯 策略	超跌反弹 + 趋势动量 + ETF跨市场配置
🕐 运行时间	个股 9:30 / ETF 9:35（工作日）
📬 通知方式	微信实时推送

📂 相关资源 #

量化代码仓库 — GitHub上的完整源码
核心脚本：paper_trader.py / stock_pool.py / stock_research.py
策略模块：strategies/bounce.py / strategies/ma_cross.py / strategies/advanced.py

由 AI 基金经理自动管理，持续进化中。

📖 股票术语速查手册

Tue, 14 Jul 2026 00:00:00 +0000

一、交易基础 #

T+1 / T+0 #

T+1：A股当天买入，第二天才能卖出（T=交易日）。 T+0：当天买的当天能卖（A股只有通过底仓做T才能实现）。

做T（日内交易） #

利用已有持仓实现变相T+0：

正T：先买后卖（早盘低吸→午后高抛）
反T：先卖后买（早盘冲高先卖→回落接回）

底仓 #

已经持有的股票仓位，是做T的前提。

仓位管理 #

术语	含义
轻仓	总资金20%以下持仓
半仓	总资金50%持仓
重仓	总资金80%以上持仓
满仓	全部资金都买了
空仓	全部卖出，持有现金
加仓	在已有持仓上继续买入
减仓	卖出一部分持仓
清仓	全部卖掉

止损 / 止盈 #

止损：价格跌到预设价位时卖出，控制亏损（如-5%强制卖）
止盈：价格涨到目标价位时卖出，锁定利润（如+6%自动卖）

二、K线与形态 #

K线组成 #

每根K线包含四个价格：开盘、收盘、最高、最低

 最高价 ───┬───
 │ │
 收盘价 ───┤ │ ← 阳线（收涨）= 空心
 开盘价 ───┤ │ ← 阴线（收跌）= 实心
 │ │
 最低价 ───┴───

常见形态 #

形态	含义
光头光脚阳线	开盘=最低，收盘=最高，极强势
长上影线	上方抛压重，冲高回落
长下影线	下方有支撑，探底回升
十字星	开盘≈收盘，变盘信号
阳包阴（吞没）	今天阳线吃掉昨天阴线 → 看涨
阴包阳	今天阴线吃掉昨天阳线 → 看跌
红三兵	连续三根阳线，上涨启动
三只乌鸦	连续三根阴线，下跌开始

三、技术指标 #

均线（MA） #

过去N天收盘价的平均值。

常用周期	代表
MA5	5日均线 = 周线，短线生命线
MA10	10日均线，短线趋势
MA20	20日均线 = 月线，中线趋势
MA30	30日均线，中线支撑
MA60	60日均线 = 季线，牛熊分界线
MA250	250日均线 = 年线，最重支撑

多头排列（上升趋势）：MA5 > MA10 > MA20 > MA30 空头排列（下降趋势）：MA5 < MA10 < MA20 < MA30

RSI（相对强弱指数） #

衡量一段时间内涨跌力度，0~100之间波动。

RSI值	含义
< 30	超卖，可能反弹（买入区）
30~50	弱势
50~70	强势
> 70	超买，可能回调（卖出区）

MACD（指数平滑异同移动平均线） #

由快线(DIF)、慢线(DEA)、柱状图组成。

信号	含义
金叉	快线上穿慢线 → 买入信号
死叉	快线下穿慢线 → 卖出信号
零轴上金叉	强势区再次走强 → 强烈买入
顶背离	价格新高但MACD没新高 → 见顶
底背离	价格新低但MACD没新低 → 见底

布林带（BOLL） #

由中轨(MA20) + 上轨(中轨+2倍标准差) + 下轨(中轨-2倍标准差)组成。

信号	含义
触碰下轨	超卖，可能反弹
触碰上轨	超买，可能回调
开口扩大	波动加剧，趋势加速
收口变窄	横盘震荡，等方向选择

四、成交量 #

术语	含义
放量	成交量明显大于前几日
缩量	成交量明显小于前几日
天量	创阶段最大成交量，常对应顶部
地量	创阶段最小成交量，常对应底部
量比	当前量 / 过去5日均量 → >1.5为放量
换手率	当日成交量 / 流通股本 → >10%为活跃

量价关系 #

价量配合	含义
价涨量增	趋势健康，资金跟进 ✅
价涨量缩	动能不足，可能到头 ⚠️
价跌量增	恐慌抛售或主力出货 ❌
价跌量缩	正常回调，卖压不大
放量突破	真突破，可以跟 🔥
缩量突破	假突破，小心诱多

五、盘口术语 #

术语	含义
开盘价	9:25集合竞价产生的价格
收盘价	15:00最后成交价
最高价	当日最高成交价
最低价	当日最低成交价
昨收	前一个交易日的收盘价
高开	开盘价 > 昨收
低开	开盘价 < 昨收
平开	开盘价 ≈ 昨收
压单	卖盘有大单压着，不让涨
托单	买盘有大单托着，不让跌
扫货	大单连续吃掉卖盘，主力进场
对倒	自买自卖，制造活跃假象
封板	涨停板上有巨量封单
炸板	涨停板被大量卖单砸开
回封	炸板后再次封死涨停

六、资金流向 #

术语	含义
主力资金	超大单(≥500万) + 大单(100~500万)净流入
散户资金	中小单净流入
北向资金	通过港股通进入A股的境外资金，被誉为"聪明钱"
净流入	主动买入成交额 - 主动卖出成交额
净流出	主动卖出 - 主动买入

资金分析口诀 #

早盘放量是真诚，尾盘拉升是偷鸡
大单净买是真涨，大单净卖是出货
北向持续流入 = 看好后市
北向连续流出 = 小心回调

七、A股特殊机制 #

术语	含义
涨跌停板	主板±10%，科创板±20%，北交所±30%
*ST / ST	特别处理股票（有退市风险）
除权除息	分红送股后股价相应下调
集合竞价	9:15~9:25 开盘前统一撮合
连续竞价	9:30~~11:30 / 13:00~~15:00 正常交易
尾盘集合竞价	14:57~15:00 收盘前统一撮合

八、量化交易专有 #

术语	含义
夏普比率	每承担1单位风险获得的超额收益，>1为优秀
最大回撤	从最高点到最低点的最大跌幅
胜率	盈利交易次数 / 总交易次数
盈亏比	平均盈利 / 平均亏损
Alpha	策略超越大盘的超额收益
Beta	策略相对大盘的波动敏感度
回测	用历史数据检验策略效果
过拟合	策略在历史数据上表现好但实盘不行
滑点	下单价与成交价之间的差异

九、常见的错误认知 #

错误说法	真相
“跌了这么多，该反弹了”	跌了还能跌，没有"该涨"这回事
“这个股票业绩好，肯定涨”	好股票也可能不涨，股价反应的是预期
“我卖的它就涨”	这叫"处置效应"，你刚好卖在低点而已
“这次不一样”	每次都一样——贪婪和恐惧从未改变
“等回本就卖”	这是最贵的几个字，止损要果断

十、常用英文缩写 #

缩写	全称	含义
PE	Price/Earnings	市盈率 = 股价/每股收益
PB	Price/Book	市净率 = 股价/每股净资产
ROE	Return on Equity	净资产收益率
EPS	Earnings Per Share	每股收益
MA	Moving Average	移动平均线
RSI	Relative Strength Index	相对强弱指数
MACD	Moving Average Convergence Divergence	指数平滑异同平均线
BOLL	Bollinger Bands	布林带
YTD	Year To Date	年初至今
QoQ	Quarter over Quarter	环比
YoY	Year over Year	同比

14 RAG 与上下文工程：检索证据而不是记住一切

Tue, 14 Jul 2026 00:00:00 +0000

结论先说：RAG 最容易做错的地方不是“没搜到”，而是“什么都往 prompt 里塞” #

很多人一提 RAG，就默认它应该尽可能多地把历史知识塞进模型上下文。这个想法在真实 Agent 系统里非常危险。

在 SecurityClaw 这种多步系统里，RAG 真正要解决的是：

当前 state 不足时，如何引入外部证据
检索到的证据如何被压缩进有限上下文预算
什么情况下 RAG 应该介入，什么情况下它反而会污染决策

一、RAG 在 Agent 里的角色不是“长期记忆”，而是“按需注入的证据层” #

你可以把它和 state / checkpoint 做一个最简区分：

层	保存什么	什么时候用
State	当前执行状态	每一步都用
Checkpoint	恢复所需结构信息	恢复时用
RAG	长期知识和历史证据	当前信息不足时用

真正的问题不是“RAG 能不能搜到”，而是：

当前这一轮推理，是否真的需要外部证据参与？

如果不需要，RAG 介入反而会把上下文弄脏。

二、一个健康的 RAG 流程应该长这样 #

flowchart TD
 Q[当前问题] --> Need{内部 state 是否足够?}
 Need -->|是| Skip[不走 RAG]
 Need -->|否| Embed[生成 query embedding]
 Embed --> Search[向量/关键词检索]
 Search --> Rerank[重排与筛选]
 Rerank --> Budget[上下文预算裁剪]
 Budget --> Inject[注入 prompt]
 Inject --> LLM[进入下一轮规划/回答]

这里真正重要的不是检索本身，而是中间两个控制点：

Rerank：不是所有检索结果都值得留下
Budget：不是所有有用结果都塞得进 prompt

三、上下文预算为什么比检索精度更容易把系统搞坏 #

如果你只关注召回率，很容易忽略一个事实：

在 Agent 系统里，过多的“相关内容”也会成为噪音。

最典型的错误做法 #

docs = retriever.retrieve(query, top_k=20)
context = "\n".join(doc.text for doc in docs)
messages.append(context)

这段逻辑的问题不是“搜得不准”，而是：

20 条文档对当前问题可能太多
每条文档长度不受控
模型会被旧证据拖偏注意力
token 被历史文本吞掉，真正规划空间反而不够

更合理的模型 #

docs = retriever.retrieve(query, top_k=20)
ranked = rerank(docs, query)
selected = take_until_token_budget(ranked, max_tokens=1200)
context = format_as_evidence(selected)

这里最重要的是 take_until_token_budget。这一步决定了系统是在“做知识注入”，还是“做信息污染”。

四、RAG 什么时候不该参与 #

这是最容易被忽略，但其实最重要的边界。

4.1 当前 state 已经足够 #

如果问题是：

当前 step 结果是什么
当前 plan 为什么失败
当前预算还剩多少

这些都属于 state / runtime，不该走 RAG。

4.2 问题本身是确定性校验 #

例如：

工具名是否合法
参数 schema 是否匹配
权限是否足够

这些应该由运行时代码直接判断，不该交给检索层。

4.3 历史知识会干扰当前判断 #

安全场景尤其明显：

当前告警和历史某次攻击长得像
但这一次实际并不是同类攻击

如果 RAG 把“相似历史”强行注入，模型很可能过度类比。

所以正确理解应该是：

RAG 不是默认参与者，而是一个条件性介入层。

五、为什么需要 rerank，而不是只用向量相似度 #

向量检索能解决“语义相似”，但不一定解决“当前任务最有用”。

比如同样都和“异常外联”相关：

一条是背景知识
一条是这个资产 3 小时前的真实行为

从语义上看两者都相关，但从当前决策价值看，显然后者更重要。

这就是 rerank 的意义：

# 伪代码：相关 ≠ 最有决策价值
ranked = reranker.score(query, docs)
selected = sorted(ranked, key=lambda x: x.decision_value, reverse=True)

你可以把 rerank 理解成：

检索负责“找得到”
重排负责“找得对”

六、Failure path：RAG 最常见的三种失败 #

6.1 召回到相似但无用的文本 #

问题不在 embedding，而在缺少重排和预算裁剪。

6.2 检索本身工作正常，但 prompt 被污染 #

这时系统看起来“召回成功”，但实际推理效果变差。

6.3 把 RAG 当成状态记忆替代品 #

这会导致每一步都重新检索同样的信息，系统不断重复喂旧证据，最后既浪费 token 又污染上下文。

七、这一篇真正要记住的框架 #

RAG 在 Agent 系统里可以压成这条链：

需要外部证据吗？
 -> 检索
 -> 重排
 -> 预算裁剪
 -> 格式化注入

真正值钱的不是“有检索”，而是：

知道何时该检索
知道检索后该保留多少
知道哪些知识不该参与当前回合

八、验证命令 #

pytest tests/ -k "rag or retrieval or context" -v

短线交易核心：资金流向 + 趋势战法

Tue, 14 Jul 2026 00:00:00 +0000

一、主力资金流向怎么看 #

什么是主力资金 #

A股把资金按单笔成交额分为三类：

类型	单笔金额	代表谁
超大单	≥500万	机构、游资大佬
大单	100万~500万	大户、基金
中小单	<100万	散户

主力资金 = 超大单 + 大单的净流入

常见的资金流向信号 #

现象	含义
价涨量增	资金真金白银在买，趋势健康
价涨量缩	没人跟了，快到头了
价跌量增	主力在出货，快跑
尾盘急拉	偷鸡摸狗，第二天大概率低开
早盘放量上攻	主力真干活，可以跟

跟主力资金的策略 #

散户跟主力 → 早盘看30分钟成交量是否放大
 → 看大单净流入是否为正
 → 确认趋势后跟着买
 → 主力开始净流出时跟着卖

二、趋势交易战法 #

趋势交易的核心就一句话：不要猜顶，不要抄底，顺着走。

趋势的三种状态 #

🟢 上升趋势：高点越来越高，低点也越来越高 → 做多
🔴 下降趋势：高点越来越低，低点也越来越低 → 空仓
⚪ 震荡趋势：横着走，没有方向 → 高抛低吸

怎么判断趋势 #

均线系统（最简单有效）：

MA5 > MA10 > MA30 → 多头排列，上升趋势 ✅
MA5 < MA10 < MA30 → 空头排列，下降趋势 ❌
MA5 / MA10 缠绕 → 震荡

价格与均线的关系：

位置	信号
价格在MA5上方	短期强势
价格回踩MA10不破	加仓点
价格跌破MA20	趋势可能结束
价格跌破MA60	趋势彻底走坏

趋势交易的具体打法 #

打法1：突破买入（追涨） #

条件：股价放量突破前期高点
买点：突破那一刻
止损：跌破突破阳线的最低点
止盈：趋势线破位

打法2：回踩买入（低吸） #

条件：上升趋势中，股价回踩MA10/MA20
买点：回踩不破均线，缩量企稳
止损：跌破均线
止盈：前高附近

打法3：连续涨停接力 #

第一天：涨停 → 关注
第二天：高开3~5%，开盘30分钟内封板 → 排板买入
第三天：如果开板就卖，不赌第四天
止损：炸板不回封 → 立刻撤

三、这些逻辑如何量化 #

我在模拟盘中加了 趋势动量策略，逻辑如下：

趋势买入条件：
1. MA5 > MA10 > MA30（多头排列）
2. 今日成交量 > 5日均量的1.3倍（放量）
3. 今日涨幅 > 2%（确认强势）
4. 近5日涨幅 > 3%（有持续性）
→ 全部满足 → 买入

趋势卖出条件：
1. 跌破MA10 → 减半
2. 跌破MA20 → 清仓
3. RSI > 75 → 超买风险，减仓

当前模拟盘的策略组合 #

策略	适用场景	应对
💥 超跌反弹（已有）	急跌后博反弹	RSI<40 + 3日跌>3%
📈 趋势动量（新增）	上升趋势中追涨	多头排列 + 放量突破

两种策略互补：跌了抄底，涨了追涨，总有一种在赚钱。

四、实战纪律 #

不管用什么策略，必须遵守：

1. 单票仓位不超过总资金20%
2. 止损5%无条件执行
3. 连续止损2次 → 停手1天
4. 不买ST股、问题股
5. 大盘趋势向下时空仓
6. 不追日内涨幅超过7%的票

没有纪律的技术分析是赌博。

回测 on 田稼禾 | 安全研究员

量化策略 v3 上线：从回测到分级门槛的完整迭代记录

一句话结论 #

起点：一个负期望系统 #

第一阶段：找 bug + 三项核心修复 #

1. 符号 bug：抄底策略实际在追高 #

2. 止损：固定比例 → 2×ATR14 #

3. 大盘过滤：接飞刀问题的第一版 #

第二阶段：探索更好的出场方式 #

第三阶段：近 30 天切片测试抓出的真问题 #

解法：分级门槛 #

当前生效规则 #

实盘观察期与回滚条件 #

必须泼的冷水 #

两轮网站打磨记：从 AI 助手悬浮入口到全文 RSS

这次的改进方式：先体检，再动手 #

第一轮：UI 与内容 #

移动端导航：basic → hybrid #

分享卡片标题统一 #

内容扩充：实习经历从 6 条到 11 条 #

全站 AI 助手悬浮入口 #

第二轮：基础设施与 SEO #

RSS 从摘要升级为全文 #

头像 LCP 优先级修正 #

内容归类修补 #

体检中确认健康的部分 #

几点新体会 #

1. 先验证「问题是否存在」，再动手修 #

2. 主题的覆盖点比想象中多 #

3. 体检要换维度做 #

ETF 龙头关注策略：跨市场配置的量化实现

一句话结论 #

一、为什么专门做 ETF，而不是都买个股 #

二、ETF 池结构（etf_pool.py） #

设计取舍 #

三、数据层的坑：ETF 代码识别 + 反爬 #

修复：识别交易所前缀 #

反爬：akshare 拿不到，走 baostock 兜底 #

四、信号计算（etf_monitor.py） #

设计取舍 #

五、与个股独立配置 + 独立推送 #

独立 cron #

增删方式（你说了算） #

六、这套池子现在长什么样 #

验证命令 #

下一步 #

个人博客全站优化记：从视觉风格到分类体系的完整升级

为什么要做这次优化 #

关于设计的思考：少即是多 #

三层分类体系搭建 #

标签云 页面 #

这次调整的文件清单 #

几个重要的原则总结 #

1. 最小改动原则 #

2. 视觉一致性比"好看"更重要 #

3. 分类体系要提前搭 #

接下来的计划 #

个人博客全站优化记：从视觉风格到分类体系的完整升级

为什么要做这次优化 #

关于设计的思考：少即是多 #

三层分类体系搭建 #

标签云 页面 #

这次调整的文件清单 #

几个重要的原则总结 #

1. 最小改动原则 #

2. 视觉一致性比"好看"更重要 #

3. 分类体系要提前搭 #

接下来的计划 #

我的个人网站安全加固与优化全记录

背景 #

第一轮：发现问题 #

🚨 High Priority #

⚠️ Medium Priority #

🔍 优化建议 #

第二轮：逐项修复 #

1. meta description 修复 #

2. 家教页完全重构 #

3. 首页卡片可点击 + hover 上浮 #

4. 自定义 404 页面 #

5. 安全响应头加固 #

二、ETF 池结构（`etf_pool.py`） #

四、信号计算（`etf_monitor.py`） #

标签云页面 #

标签云页面 #