全部文章

八十行出头的自用脚本，只清自己空间的粉丝。用 DrissionPage 接管本机一个已经登录的浏览器，打开自己空间的粉丝页，按每张卡片上那个按钮的文案定去留：写着「已互粉」的跳过，其余点开「更多」→「移除粉丝」→ 确认。判据只有文案，翻页靠点分页条的下按钮。不是操作建议，也不涉及别人的账号。

因子平台的机器只有 908MB 内存，宽表这条路什么时候撞墙我一直没量过。同一批截面因子计算，numpy 走 date×code 矩阵、polars 走长表表达式、duckdb 走 SQL 窗口函数，各跑一遍：numpy 纯计算最快，端到端反而最慢；中途还踩到一个千分之一脏数据改掉整张宽表时间轴的坑。

qd.qidiquant.com 把缠论买卖点、潮汐跟势、阶梯趋势、主升段捕捉、趋势低吸五套战法放进真实历史行情里回测。这篇讲它的成交口径：信号带可知时刻、下根开盘成交、结构没冻结就不交易，佣金万 2.5、卖出印花税万 5、滑点千 1、整手约束全部计入，出场顺序固定，结果与 Rust 那版实现对拍过 45 组快照。

aifactor.qidiquant.com 上是两千多个公开可见的 A 股因子，每个都带一份基于本地前复权日线的绩效报告。这篇讲清那些数字怎么算出来的：t-1 收盘信号 t 日持有、横截面两头各取 20%、年化按 250 个交易日、不计手续费滑点，以及 AI 生成的因子入库前过的是哪一关。

两个标准 ENV：不写 .pyc（容器里没用），stdout/stderr 不缓冲（日志实时可见——容器排障全靠日志）。

为什么第一件事是跑测试而不是写代码：这是"改动可被验证"的起点。基线绿了，之后你改坏的任何东西都能被立刻发现；基线红了，先搞清楚为什么——带着失败基线开发等于蒙眼开车。

02 篇定的选型，这里展开理由：

每个路由文件导出一个 build_router(deps: dict) -> APIRouter，main.py 统一装配：

运营的真实需求："每周把销售 CSV 丢进去，自动校验数据 → 算汇总 → AI 出报告"。这是多步骤流程，不是一次对话。

员工在对话里问"FBA 发货要注意什么"，后端发生什么（摘自 chat_router._prepare_chat）：

@abstractmethod def chat(self, messages: list[dict], model: str | None = None) -> str: ...

注册时把明文口令变成数据库里的两列：