应用日志监控擅长发现异常，却很少覆盖异常发生后的诊断与处置。关键词命中次数、错误率和响应时间一旦超过阈值，监控系统可以迅速发出告警；但错误是否来自同一根因、影响了哪些服务、是否需要立即控制影响，通常仍要由工程师接手判断。 墨天轮原有的日志监控也是如此。2026 年 7 月 10 日，外部监控只告诉我后端程序出现了 74 条 ERROR。我根据这条告警手工创建了 issue_49，初始信息只有报错数量和日志目录： 接到告警说后端程序 ERROR 报错 74 个， 请看看是什么报错。 issue_49 随后通过 Agent 连接两台应用节点，重新统计完整日志：一个节点有 113 条 ERROR，另一个节点有 80 条，合计 193 条。因此，Issue 标题中的 74 和分析结果中的 193 属于不同统计口径：74 是外部监控传来的初始告警值，193 是 Agent 扫描两台服务器后得到的完整 ERROR 总量。分析过程中又识别出 74 条短信验证码高频请求，但这是错误分类结果，不能代替完整日志总量。Opsx 继续完成错误分类和根因分析，但触发链路仍然存在断层：第三方平台发现异常，人把告警数量转述给 Opsx，再手工创建 Issue。只要人没有及时转述，后续分析和处理就不会开始。 单一的报错数量也不足以回答生产处置真正关心的问题： 74 条 ERROR 是 74 个不同问题，还是同一个问题重复了 74 次？ 错误来自哪个应用副本、哪个接口和哪个用户或 IP？ 是程序 Bug、数据库故障、外部依赖异常，还是攻击流量？ 服务是否已经恢复，是否需要立即介入？ 如果属于已知问题，能否直接复用历史结论和处置方法？ 因此，这次实践不只是增强告警后的分析，而是替换这条依赖第三方监控和人工转述的入口：由 Opsx 的 Shell Schedule 每 10 分钟直接扫描两台应用服务器的增量日志；ERROR 超过阈值后自动创建资产关联 Issue，对满足明确规则的已知问题先执行处置，再由 Agent 分析根因、验证结果，并把发现、动作和结论保存在同一个运维上下文中。 ...

最近我在 Opsx 中导入了一套 PostgreSQL 巡检 Skill。 它不是一段单独的提示词，而是一个完整目录：里面有 800 多行的 SKILL.md、一份 2,000 多行的 Shell 脚本，还有数据库连接配置示例。过去，这类东西通常放在 DBA 的电脑、运维仓库或者某台服务器上。谁要用，谁就把文件复制过去，再根据目标数据库调整环境。 这一次我想验证的是另一件事：能不能让 Opsx 保存完整的巡检方法，在任务发生时，把 Skill、数据库资产和执行环境组合起来，再交给 OpenCode 和 LLM 使用？ 如果这条链路成立，留下来的就不只是一份健康报告，而是一项可以继续交给不同 Agent、不同 LLM 和不同 PostgreSQL 资产使用的平台能力。 这次实践使用了两个真实对象： kw_156：导入 Opsx 的 db-server-healthcheck-postgresql Skill； issue_122：使用该 Skill 执行 PostgreSQL 健康巡检的 Issue。 巡检已经完成，整体结论为 Warning。数据库当时没有阻塞、长事务、严重表膨胀或 XID 回卷风险，但磁盘、WAL 归档、日志、安全配置、部分表结构以及 PostgreSQL 版本都存在需要继续处理的问题。 Skill 是 Multi-Agent 平台的基础设施 对于任何 Multi-Agent 或 AI 平台，Agent 和 LLM 只解决了“由谁思考、由谁执行”的问题。平台还必须回答另一个问题：专业能力从哪里来，又怎样被不同执行端复用？ 这个承载专业能力的基本单元就是 Skill。数据库巡检、Kubernetes 排障、日志分析、备份校验等任务，都不应该每次只依靠 LLM 临时生成命令，而需要已经验证过的说明、脚本、参考资料、阈值和安全边界。 因此，内置 Skill 和导入外部 Skill 不是锦上添花，而是 Multi-Agent 平台的基础能力。如果 Skill 仍然分别安装在 OpenCode、Claude Code 或其他 Agent 的本地目录中，就会出现新的孤岛： ...

生成式 AI 普及以后，技术用户获取答案的方式正在发生变化。一部分原本需要访问社区、搜索历史问答或发布新问题的需求，被 AI 对话直接承接。对技术社区而言，真实用户访问和 UGC 活跃度承受压力并不意外。Stack Overflow 也曾在官方流量分析中披露，GPT-4 发布后的 2023 年 4 月出现过约 14% 的超常流量下降。 墨天轮的数据一度呈现出相反现象：在行业真实流量承压的背景下，网站访问指标没有下降，反而增长了数倍。按照过去以日活、月活为核心的运营口径，这原本应该是一个非常好的结果；但同期 UGC 产出，以及用户登录、签到等能够确认的互动数据并没有同步增长，部分指标反而在下降。 继续核对 CDN、NGINX 和应用日志后，指标之间的矛盾才得到解释。传统搜索引擎蜘蛛的流量变化很小，对这轮指标增长的影响可以忽略；真正抬高访问量的是大量伪装成普通浏览器的程序化抓取请求。它们的目的无法从访问日志直接证明：可能是搬运网站内容，可能是构建本地知识库，也可能用于大模型训练。能够确认的是，这些请求没有带来相应的登录、签到或内容互动，却被计入了原有的流量、日活和月活指标。 第一阶段，我先用 User-Agent 黑名单处理能够明确识别的低价值抓取请求。当前实际规则如下，Googlebot 和 Bingbot 没有进入名单，因此不会在这一层被拦截。下面为了阅读做了换行，CDN 中保存的实际配置仍是一条连续规则： *YisouSpider*|*Baiduspider*|*python-requests*|*Go-http-client*|*okhttp*|*Apache-HttpClient*|*Sogou*|*Firefox/3.0*|*Windows NT 5.1*|*360Spider*|*AhrefsBot*|*Windows NT 6.1*|pc|axios/1.7.7|*Bytespider* 这份名单不只包含一搜、百度、搜狗、360、Ahrefs 和 Bytespider 等已知蜘蛛，也覆盖 python-requests、Go-http-client、okhttp、Apache-HttpClient、axios 等常见程序化客户端，以及根据当前业务访问特征确认不再需要的旧客户端标识。规则生效后，CDN 侧流量下降约 30%，说明这一层简单、确定且几乎没有运行成本的过滤已经处理了相当比例的非用户请求。 但这一步很快遇到边界。剩余 Bot 不再使用固定的爬虫 User-Agent，而是伪装成 Chrome 等普通浏览器；有些还使用 IP 池轮换来源，把请求分散到同一网段的多个地址。单看某一个 IP，请求量可能并不突出；聚合到 /24 网段后，持续抓取的特征才会显现。只依赖 User-Agent 或单 IP 黑名单，已经无法继续识别这部分流量。 问题因此不再只是“访问量太大”。爬虫流量一方面污染运营指标，使表面增长与登录、签到、UGC 等互动指标发生背离；另一方面持续消耗 CDN、源站服务器和 OSS 资源。对于以原创技术内容为核心的网站，它还带来内容被批量获取的风险： CDN、源站服务器和 OSS 都在为它们消耗流量、连接和计算资源； 原创内容被外部平台批量抓取和搬运，墨天轮承担内容生产与分发成本，内容价值却被外部平台直接复用。 云 WAF 和 Cloudflare 都是可以考虑的方案，但并不适合直接套用到当前场景。WAF 的 Bot 识别与定制能力难以完整覆盖内容型网站的业务规则，整体费用也比较高；Cloudflare 在中国大陆的接入还有额外条件，其官方 China Network 文档要求先使用 Enterprise Plan，再单独订阅中国网络，并由合作方审核域名。 ...

Opsx 支持将代码仓库作为 Repo Asset 管理，并让 Agent 在指定仓库中读取和修改代码。整个过程不依赖开发者本地 IDE，代码差异、提交记录和恢复路径仍由 Git 管理。 MES Workspace 下的 issue_50 和 issue_77 分别验证了仓库查询与代码修改能力。 从 Repo Asset 定位代码 Repo Asset 保存仓库的稳定身份和执行上下文，包括： 仓库类型、技术栈和默认分支； Runtime 中的工作目录； 源码仓库与应用服务的关联关系； 能够访问该仓库的 Runtime。 创建 Issue 时只需绑定目标 Repo Asset。Opsx 根据资产与 Runtime 的映射，将任务交给具备仓库访问能力的 Agent，无需在 Prompt 中重复提供主机、路径和分支信息。 issue_50 绑定 Java 后端仓库 repo-enmo-support。Claude Runner 读取 Asset Metadata 后，在对应 Runtime 中执行 Git 查询，确认仓库包含四个远端分支：dev、master、report 和 word，默认分支为 dev。 Execution 先执行 git fetch --all --prune 更新远端引用，再通过 git branch -r 返回分支清单。 ...

前言 上周在GitHub上一个BettaFish项目很火，再次看到MindSpider项目，以及之前看到的MediaCrawler项目，支持采集多个热门社交平台的相关数据，我将BettaFish在一台老MAC上部署跑起来了（主要逻辑就是在不同渠道不停的搜负面词语。不过针对数据量少的关键字效果一般，只要出现一点错误就会被无限放大），MindSpider & MediaCrawler实在跑不起来，项目太重，每次playwright调起Chromium都被反爬，尝试修复一段时候后担心账号被封还是放弃了。 回头想想垂直领域直接用浏览器插件就可以搞定，大的舆情监测直接花钱买服务或者API接口。 于是周末我用 Trae SOLO 花了半个下午，撸了一个 Chrome 浏览器插件，核心功能： 抖音 / 小红书 搜索页 和 详情页 均可一键采集 自动识别 一级 与 二级 评论，用 parent_id 关联 导出 CSV（UTF-8 BOM），Excel 直接打开即可透视 全程 0 后端，纯前端离线运行，隐私无上传 下面聊聊技术实现与踩坑。 一、整体架构 ├─ manifest.json // 权限声明 + 注入规则 ├─ content.js // 页面脚本，负责 DOM 解析、数据缓存、CSV 生成 ├─ background.js // 扩展后台，只负责下载文件 ├─ styles.css // 悬浮按钮样式 └─ README.md content 脚本 同时注入 douyin.com 与 xiaohongshu.com，按 hostname 自动路由 用 Map() 做内存数据库，键为 videoId / noteId，值为元数据 + 评论数组 采集完成后调用 chrome.runtime.sendMessage() 把 Blob 传给 background 触发下载 二、核心难点 1. 动态 DOM + 哈希 class 抖音&小红书前端都是 React 同构 + 随机类名，class="HtBH2h0B" 下次就变了。 解法： ...

作为一个专业领域的技术专家，我需要实时了解全面的信息。市面上的RSS工具要么功能复杂臃肿，要么部分需求不支持，最大的问题是不能在同一个平台浏览所有信息源。经过一番调研，我决定用Kiro写一个轻量级的RSS聚合工具。 令人惊喜的是，一个周末就完成了整个系统，并成功同步了近5000篇文章（标题+链接）。这篇文章将详细介绍整体架构和实现的技术难点，展示Kiro在复杂系统开发中的不凡能力。 先放一些截图吧。 Kiro开发界面，可以看到整个项目完成差不多只用了不到 200 Bonus，实际编码时间估计也就1天时间。 Web首页（没有做任何UI调教，自己凑合能用），支持浏览最新资讯，筛选搜索，采集特定文章。 网站管理页面，主要是指定标题、链接、时间的元素。且支持API方式获取，同样配置好JSON匹配规则。 微信公众号管理页面，公众号支持批量导入，图标转存到了腾讯云，否则防盗链无法展示，可以设置同步页数/同步间隔，同时记录了最后同步时间。 还有一个页面主要记录微信管理员cookie，比较简单就不展示了。另外针对部分文章会采集转换成markdown格式存储到本地，图片也做了处理，文章可以正常展示，后续打算基于有价值的文章做一个垂直领域的RAG。 （以下绝大部分直接用Kiro在项目中生成） 系统需求分析 核心需求 多源聚合：支持传统网站RSS、API接口、微信公众号文章 统一管理：在同一个平台浏览和管理所有信息源 智能处理：自动去重、内容清理、图片处理、HTML转Markdown Web界面：提供直观的管理和浏览界面 文章同步：将RSS文章同步到标准化的articles表 高性能：支持大量文章的存储和检索 技术挑战 异构数据源整合：不同平台的数据格式差异巨大 微信反爬虫：微信公众号的访问限制和安全机制 API网站支持：政府部门API接口的调用和数据转换 内容处理：HTML转Markdown、图片上传COS、推广内容清理 数据一致性：避免重复文章，保证数据完整性 性能优化：大量文章的存储和快速检索 多管理员机制：微信账号轮换和频率限制处理 系统架构设计 整体架构 ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ 数据采集层 │ │ 数据处理层 │ │ 应用服务层 │ ├─────────────────┤ ├─────────────────┤ ├─────────────────┤ │ • 网站爬虫 │ │ • 内容清理 │ │ • Web管理界面 │ │ • 微信爬虫 │ │ • 图片处理 │ │ • REST API │ │ • API接口 │ │ • 格式转换 │ │ • 文章同步 │ │ • 多管理员轮换 │ │ • HTML转MD │ │ • 一键采集 │ └─────────────────┘ └─────────────────┘ └─────────────────┘ │ │ │ └───────────────────────┼───────────────────────┘ │ ┌─────────────────┐ │ 数据存储层 │ ├─────────────────┤ │ • PostgreSQL │ │ • 腾讯云COS │ │ • 双表结构 │ └─────────────────┘ 数据流架构 原始数据源 → RSS采集表 → 内容处理 → 标准化文章表 → Web展示 ↓ ↓ ↓ ↓ ↓ 网站/API rss_articles 图片上传 articles 用户界面 微信公众号 _list HTML转MD 表 管理后台 核心模块 1. 数据库设计 (database.py) 采用PostgreSQL作为主数据库，设计了双表结构： ...

项目缘起 这是我在国庆期间完成的第二个Vibe项目，前后端代码接近10万行，数据库28张表，全部由我一个人独立完成。 项目起源于一个非常私人的需求：大女儿青云明年就要上小学了，我在查学校、学区、政策时遇到了很多障碍。作为一个技术人，实在无法忍受这种信息不对称和查询困难，于是就有了这个项目。 开发过程很有意思：首先花了几天时间跟GPT反复讨论需求，确定产品方向；然后通过各种AI工具采集整理汇总学校的各种信息，包括对口划片、中/高考成绩、分配生政策等；最后实现了资讯、问答、用户及权限等模块，甚至还做了个排行榜。（BTW：LOGO是用GPT生成）。 老规矩，先上几张图： 项目概述 这是一个面向教育行业的综合信息平台，提供学校信息查询、对口划片、升学政策、排行榜计算等功能。项目采用前后端分离架构，由我一个人独立完成全部开发工作，包括前端30+页面组件、后端20+业务模块、28张数据库表的设计与实现。 技术架构 前端技术栈 框架: React 18 + TypeScript + Vite 路由: React Router v6 状态管理: Zustand UI组件: 自研组件库 SEO优化: React Helmet Async 构建工具: Vite 后端技术栈 运行环境: Node.js + Express 数据库: PostgreSQL 认证授权: JWT + Session双重认证 文件存储: 腾讯云COS对象存储 邮箱服务: 腾讯云邮箱 地图服务: 百度地图API 搜索服务：腾讯云WSA+阿里云IQS AI服务: 阿里云QWEN大模型 前端功能架构 基于React Router的路由架构，实现了完整的前端功能模块： 1. 学校信息模块 graph TD A[首页] --> B[学校信息模块] B --> B1[学校列表] B --> B2[学校详情] B2 --> B2_1[学校概览] B2 --> B2_2[学校简介] B2 --> B2_3[荣誉奖项] B2 --> B2_4[特色项目] B2 --> B2_5[校园风采] B2 --> B2_6[相关资讯和问答] B2 --> B2_7[对口小区和初中] B2 --> B2_8[中考高考成绩] B2 --> B2_9[综合评价] B --> B3[学区查询] B --> B4[学校地图] 2. 排行榜模块 graph TD A[首页] --> C[排行榜模块] C --> C1[小学排行] C --> C2[初中排行] C --> C3[高中排行] 3. 社区问答模块 graph TD A[首页] --> D[问答模块] D --> D1[问答首页] D --> D2[问题详情] D --> D3[提问页面] 4. 文章资讯模块 graph TD A[首页] --> E[文章资讯模块] E --> E1[文章列表] E --> E2[文章详情] E --> E3[文章编辑] E --> E4[文章发布] style E3 fill:#ffcccc style E4 fill:#ffcccc 5. 用户中心模块 graph TD A[首页] --> F[用户中心模块] F --> F1[用户注册] F --> F2[用户登录] F --> F3[用户中心] F --> F4[安全设置] F --> F5[收藏页面] 6. 分配生政策模块 graph TD A[首页] --> G[分配生政策模块] G --> G1[分配生详情] G --> G2[配额管理] style G2 fill:#ffcccc 7. 关系管理模块 graph TD A[首页] --> H[关系管理模块] H --> H1[小区对口关系] H --> H2[初中对口关系] H --> H3[关系操作] style H3 fill:#ffcccc 8. 管理模块 graph TD A[首页] --> I[管理模块] I --> I1[学校管理] I --> I2[地图管理] I --> I3[排名管理] style I1 fill:#ffcccc style I2 fill:#ffcccc style I3 fill:#ffcccc 真实技术难点 1. 腾讯云COS对象存储集成 文件路径: xueapp/routes/photos.js ...

春节假期，deepseek火出了圈。我用字节发布的免费AI编程IDE工具Trae手搓了一个企业级应用——家庭健康宝，前端/后端/数据库/对象存储/大模型一把梭！ 用于统一管理家人病历、检验单、药品、保单、体检、身高等各种健康数据。支持文件阅览及OCR智能解析；接入阿里千问大模型，可以将健康数据发给大模型咨询；累计的健康数据可以生成趋势图表；同时支持全文检索；还有未来健康事件的提醒功能。 家庭健康宝思维导图 节前在项目中用cursor体验了一些代码改写的功能，大为震惊。随后字节发布了Trae免费的平替平台，就想着用他来做一个完整的应用程序。 作为两个女儿的奶爸，刚好前几天女儿肺炎来回跑了几个医院，病历/检测报告到处都是，就萌生了做一个家庭健康数据管理的小程序。 前期用ChatGPT、Kimi、Deepseek讨论产品命名、竞品分析、商业计划、模块设计、架构选择等等，可以说绝大多数问题都会先丢给大模型，让他给一些未知的反馈。 而后上手Tare开始编写各种demo验证，虽然有一些前后端编程的经验，但是工作中更多的角色是产品经理，所以虽然有AI加持还是遇到了一些坎坷，不过从过去做互联网产品的经验来说，就没有过不了的坎。 首页摘要 健康数据 提醒 全文搜索 健康数据趋势 智能助手 火炉旁、汽车上、婚礼中都在与Trae亲密沟通协作，下达指令立马专业反馈执行，磨合后效率不断提升，其实它什么都知道，如果你没得到正确的答案真的可能是你没问对。最终在春节假期里一个人零投入完成了一个算得上是企业级的小程序，我想过去至少5人团队要做3个月。 后端工程 前端工程 后端数据库 这几天抽空填充了一些数据，整体UI还过得去，先自用一段时间，后续再考虑是否发布出来。另外我还有几个其他产品的想法，得益于AI的神力，我想这些珍贵的idea都能快速实现，这个世界正在被重新制造。

最近在例行逛竞品时，发现CSDN推出了云服务的功能，号称联合国内顶级云厂商，共同为开发者提供稳定便宜的云服务，全网最低价。提供的产品有计算、数据库、存储、网络、网络、网站备案这几个基础的云资源，截图如下： IaaS 虽然是一块红海，但是随着当前竞争形势已经非常激烈（运营商杀入、国资云、AWS微软），而且早些年就已经出现了头部3家占据70%市场的局面，尾部的一些云厂商为了生存只能转战私有云卖自己整套的云底座，很难想象CSDN在这个时间节点推出开发云的用意，如果是基于IaaS资源推出一些个性化垂直群体的PaaS、SaaS产品还可以想象一下。 首先云服务是一项技术门槛高、成本高、利润低的产业，亚马逊从03年开始做AWS现在有几万员工，微软也是在萨蒂亚接任CEO后全面转战云计算，阿里云现在也有上万员工了，这三家在2021年全球市场占有率分别是40%、21%、10%，所以云计算如果不能利用先发优势形成产业规模很难走通商业逻辑，已经容不下新的玩家，如果是直接代理、分销云厂商的资源或许还能拿到不错的佣金。 再来看目标群体 大型组织：处于担忧云的安全和稳定阶段、致力于构建私有云，几乎不太可能采购CSDN的云服务 中小企业：云资源采购通常是企业行为，决策路径比个人要长很多，另外采购也是优先选择头部阿里云、华为云，这些头部云厂商争夺市场，各种营销补贴优惠。所以实在也想不到用CSDN云服务的理由 个人：CSDN有用广大的开发者群体，看上去应该是主要的目标群体。但是对个人来说，客单价低，盈利几乎不可能，而且购买服务器的需求也越来越少（微信公众号之前还流行买服务器搭建自己的博客网站），另外多数开发者都会去薅云厂商的羊毛，比如亚马逊麻烦试用、9.9腾讯云一年的羊毛。如果是买来用于学习的场景，目前大多数电脑都是16G+的高配，一条docker命令就能起一个测试环境，付费的意愿也就没那么高了。 最近看到阿里、华为、腾讯、京东几乎都有50元一年的2C2G4M的云主机，头部云厂商的战略很明显，云主机只是最基础的服务，引导上云后逐步使用其他云服务，补贴的云主机费用就是变现的获客成本。 而以云主机为主打产品的CSDN开发云，补贴不起，所以1CPU/2GB/4Mbps显示4.5折后还要1139.94元，毫无优势可言。 从各方面来说云计算基础服务显然是上错了舞台，有点类似在有三大电信运营商下进入通讯领域，在有国网、南网的情况下进入电力行业。 最晚进入云服务这个赛道的大厂，应该就是字节跳动在2020年推出的火山引擎，首先字节基于内部云服务的需求，积累了大量相关技术和真实案例。主推的云服务是视频与内容分发，另外两个数据增长平台和智能应用也是字节的优势方向，通过云上服务化的方式将抖音和今日头条的相关技术提供给外部企业，虽入局稍晚，但是差异化的优势明显，相信未来火山引擎能分到云服务的一块蛋糕。 目前CSDN全国有近800左右的员工，发展也有20多年，内部估值肯定是不低于10亿，这个体量被收购的可能性极小，商业落地能力越来越弱，上市难度也很大。，CSDN虽然是中国第一大开发者社区，但是完美错过了需求管理、代码仓库、教育培训、服务众包、原型设计、设计协作等开发者息息相关且能够变现的产品形态，后面的路怎么走？艰难坎坷、荆棘载途！ 2022-11-16 Update: 最近看了一眼CSDN的云服务官网，有种进了腾讯云官网的感觉，海外云主机也成为主推产品。也加了分销和码龄抵现，然而并没有什么銮用吧。另外，以下是双十一国内三大云厂商的促销： [腾讯云双11活动] 2核2G4M，50元/1年 2核4G6M，100元/1年 4核8G10M，300元/1年 [华为云双11活动] 1核2G1M，35元/1年 2核4G2M，116元/1年 [阿里云双11活动] 2核2G1M，49元/1年 2023-04-05 Update: 目前开发云已经从CSDN主导航上去掉。

以下是我2021年招聘互联网运营时的一些面试题，供大家参考。运营也在不断变化，而且越来越快，如果当下再招，面试题应该会有很大的变化，后期岗位开放我会再更新一版。 基本介绍 介绍一下上一份工作中自己主要负责的事情，目标，成果，考核指标 用户、活动、内容运营，你对哪一块最感兴趣、最擅长哪一个 详细探讨 对近期热点事件进行点评，想出一个与产品相关联的推广方案或者活动 黑客增长知道吗？核心内容是什么，有这方面的实践和想法吗？ 搜索引擎SEO有没有做过，关键字 问答营销有没有做过，知乎，百度知道 关于投广告你怎么看？效果 如何提升日活？PV 如何提升UGC？ 漏斗转化模型了解吗？如何应用到实际的工作中 怎么看目前的私域流量和KOL? 编写一篇内容，哪些因素是需要首先考虑的? 有哪些渠道进行推广? 今日头条、抖音为什么在短时间内这么火？ 给程序员打标签 有学过编程语言吗？ 运营需要哪些数据来支持，举一个数据分析调整方案取得效果的案例 如何看待数据驱动运营，运营驱动产品？ 怎么看待标题党，震惊了？ 对我们公司产品有什么想法，有哪些需要改进的？ 补充信息 你觉得自己还有哪些优点，可以补充一下 离职原因 期望薪资 对自己的规划 最近有在学习什么课程、书籍，可以分享一下吗 你有什么问题需要问我吗？