158 lines
6.2 KiB
Markdown
158 lines
6.2 KiB
Markdown
# Daily News for Markyan04 Editorial Constraints
|
||
|
||
本仓库用于生成和发送 **Daily News for Markyan04**，一份每天早上的中文个人报纸。
|
||
|
||
它不是通用科技 newsletter，也不是申请提醒。它应该像一份压缩后的早报：先说明当天真正发生了什么，再补充必要背景，最后把技术、金融和安全信息整理到可长期阅读的结构里。
|
||
|
||
## 输出契约
|
||
|
||
每天生成一封邮件。
|
||
|
||
标题格式：
|
||
|
||
```text
|
||
Daily News for Markyan04 | YYYY - MM - DD
|
||
```
|
||
|
||
正文必须使用中文。常见英文技术词保留英文，例如 `RAG`、`agent`、`vibe coding`、`LLMOps`、`MCP`、`eBPF`、`KYC / AML`。
|
||
|
||
邮件栏目顺序固定为：
|
||
|
||
1. 今日汇总
|
||
2. 传统新闻
|
||
3. AI领域
|
||
4. 传统软工
|
||
5. 安全与性能工程
|
||
6. GitHub / 开源项目跟踪
|
||
7. 金融领域
|
||
|
||
目标权重：
|
||
|
||
- 今日汇总：5%
|
||
- 传统新闻：15%
|
||
- AI领域：35%
|
||
- 传统软工：15%
|
||
- 安全与性能工程：12%
|
||
- GitHub / 开源项目跟踪：10%
|
||
- 金融领域：8%
|
||
|
||
最终邮件应当信息密度高、选择克制，适合 8-12 分钟读完。
|
||
|
||
## 写作原则
|
||
|
||
- 每次生成前必须重新采集来源，不得把模型记忆当成新闻来源。
|
||
- 新闻型条目必须有来源 URL，并带有发布时间、更新时间或采集时间。
|
||
- 不要重复过去几期已经写过的同一事件；除非出现重大新进展，才可以再次报道，并且要说明新增事实。
|
||
- 不要使用“为何重要”“学习启示”“对你来说”“建议关注”这类模板化分段词。
|
||
- 标准信息放在标题下方的 metadata 行，例如：`来源：BBC World | 时间：2026-07-05 | 链接：https://...`。
|
||
- 正文以自然文段写作，优先概括事实本身：谁做了什么、何时发生、涉及哪些地区或机构、当前进展是什么、还有哪些不确定性。
|
||
- 可以解释影响，但解释必须服务于理解事件，不要只说“这很重要”而不交代事件内容。
|
||
- 不要直接对读者进行个人化说教，不要写“你应该学习”“对你而言”。
|
||
- 不要加入每日行动清单、实习就业板块、英语写作练习或申请动态板块。
|
||
- 重要论文、技术报告、benchmark 放进 `AI领域`，不单独设研究动态。
|
||
- 不追踪用户自己的 GitHub 项目，除非用户明确要求。
|
||
|
||
## 栏目要求
|
||
|
||
### 1. 今日汇总
|
||
|
||
最多 5 条，覆盖当天最值得读的内容。可以使用短 bullet，但要总结具体事件，不要只写意义。
|
||
|
||
示例：
|
||
|
||
```text
|
||
- 传统新闻：...
|
||
- AI：...
|
||
- 安全：...
|
||
- GitHub：...
|
||
- 金融：...
|
||
```
|
||
|
||
### 2. 传统新闻
|
||
|
||
覆盖国际政治、地缘冲突、中国与香港政策、金融监管、宏观经济和亚太地区重要事件。
|
||
|
||
优先主题包括：
|
||
|
||
- 中美关系、特朗普政府相关政策、访华或外交动态。
|
||
- 俄乌战争及其外交、军事、能源、制裁进展。
|
||
- 中国内地与香港金融监管，例如证监会、港交所、香港证监会、金管局的重要动作。
|
||
- 影响科技、金融和全球供应链的政策新闻。
|
||
|
||
使用成熟新闻机构和官方监管机构来源。二手媒体报道可以用于发现，但重大政策和监管内容应尽量回到官方来源核验。
|
||
|
||
### 3. AI领域
|
||
|
||
这是主栏目，覆盖前沿新闻和工程理解。
|
||
|
||
扫描范围包括：
|
||
|
||
- 大模型发布、能力更新和产品变化。
|
||
- AI coding tools、coding agents、vibe coding 工作流。
|
||
- agent 框架、工具调用、MCP、多 agent 系统、工作流编排。
|
||
- AI engineering / LLMOps：评测、可观测性、路由、guardrails、推理、缓存、部署、成本、可靠性。
|
||
- RAG、GraphRAG、长上下文、memory、retrieval evaluation。
|
||
- 多模态 AI、UI agents、computer-use agents。
|
||
- 开源模型与推理基础设施。
|
||
- AI security：prompt injection、数据泄露、沙箱、agent 风险。
|
||
- 进入工程实践的新词和新概念。
|
||
- 高价值论文、benchmark 或技术报告。
|
||
|
||
每天选择约 5-8 条。优先最近 24-72 小时内的实质更新；可以保留少量背景解释，但必须由近期事件触发。
|
||
|
||
### 4. 传统软工
|
||
|
||
关注耐用的软件工程知识和工业级实践：
|
||
|
||
- Backend：Spring Boot、FastAPI、API 设计、auth、服务边界。
|
||
- Frontend：Vue、TypeScript、构建系统、状态管理、测试。
|
||
- Database：PostgreSQL、MySQL、索引、事务、查询计划、缓存。
|
||
- DevOps：Docker、CI/CD、Nginx、Linux service、Sentry、observability。
|
||
- Testing：E2E、contract test、load test、回归策略。
|
||
- 事故复盘、生产故障分析、可维护性和技术债。
|
||
|
||
避免初级教程，除非它解释了常被误解的重要概念。
|
||
|
||
### 5. 安全与性能工程
|
||
|
||
覆盖安全漏洞、GFW / 网络测量和系统性能。
|
||
|
||
安全条目应包括漏洞编号或名称、受影响系统、利用状态、当前处置或缓解方向。不得提供攻击步骤、绕过审查教程或可操作规避指南。
|
||
|
||
性能条目优先 Linux performance、`perf`、`eBPF`、FlameGraph、scheduler、memory、IO、networking、Android Perfetto、数据库和后端延迟分析。
|
||
|
||
### 6. GitHub / 开源项目跟踪
|
||
|
||
只跟踪外部高价值项目。
|
||
|
||
优先类别：
|
||
|
||
- AI agents 和 coding agents。
|
||
- LLM infrastructure。
|
||
- RAG 与 evaluation tools。
|
||
- Developer tools。
|
||
- Security tools。
|
||
- Performance engineering tools。
|
||
- Fintech 相关基础设施。
|
||
|
||
项目摘要要说明它在做什么、为什么最近被关注、技术栈或架构特征、成熟度。避免低质量 prompt collection、壳包装、营销 demo 和长期无人维护项目。
|
||
|
||
### 7. 金融领域
|
||
|
||
这是金融系统和 fintech 素养栏目，不提供个性化投资建议。
|
||
|
||
优先主题：
|
||
|
||
- 利率、债券、收益率曲线、ETF、流动性、做市、清算与结算。
|
||
- 支付、清算、风控、反欺诈、`KYC / AML`、open banking。
|
||
- 稳定币、tokenization、CBDC 和金融基础设施。
|
||
- AI in finance：风控模型、欺诈检测、研究助手、文档处理、合规。
|
||
- HKMA、MAS、BIS、SEC、Fed、交易所等机构动态。
|
||
|
||
## 来源和归档
|
||
|
||
来源规则在 `config/sources.yaml`。投递和归档规则在 `config/delivery.yaml`。
|
||
|
||
发送前必须写入 `newspaper/` 下的 Markdown、HTML 和 metadata JSON。不要把 SMTP 授权码、DeepSeek API key、cookie 或 session token 写入仓库。
|
||
|